《Test Driven Development: By Example》一书

核心思想

• Rules
  • Write new code only if you first have a failing automated test.
  • Eliminate duplication.
• Red/green/refactor. The TDDs mantra.
  • Red: write a little test that doesn’t work, perhaps doesn’t even compile at first
  • Green: make the test work quickly, committing whatever sins necessary in the process
  • Refactor: eliminate all the duplication created in just getting the test to work

By Example

• 首先，来了一个需求，不是思考需要一个什么对象，需要一个什么方法，而是需要一个什么测试，来验证我们的实现是正确的
• 更进一步的，是需求可测试化：需求不是一句话，而是一个todo list，其实就是所有的（尽量）测例，有什么需求都通过测例来描述，在什么情况下软件应该是什么行为，要细化到可以直接翻译为代码
• 思考需要解决的问题的时候，都是以：我需要什么样的测试以验证实现正确开始，而不是如何实现
• 测试化的需求可能繁简程度不一，那么就需要先从简单的开始，同时学会把复杂的测例拆分为简单的测例
• 为尚不存在的代码编写测例时，首先假设它有完美的接口满足其功能，同时先不要管封装、数据类型等复杂问题，让测试代码尽量简单，例如：

   public void testMultiplication() { 
       Dollar five= new Dollar(5); 
       five.times(2);
       assertEquals(10, five.amount);
   }
  

• 一步一步来，先让让测例写出来，但同时要记下需要改善的地方，先写出一个可以跑，但是失败的测例，然后再逐步实现、逐步改善测例与实现
• 编写的测例首先应该是不能编译的，借助IDE，我们可以很方便的添加相应的类、成员、方法，使得测例能够编译，注意！这一步不要加入任何实现，仅仅让测例可编译，一旦加入了实现，就容易沉浸在实现中了
• 测例运行起来当然是失败的，但这是巨大的进步！从“实现XX功能”，到“让这个测例通过”，简单了无数倍！
• TDD五部曲，有点naive，但值得借鉴
  • Add a little test
  • Run all tests and fail
  • Make a little change，最小改动，例如直接把amount初始值赋值为10
  • Run the tests and succeed
  • Refactor to remove duplication

• 好代码的“天敌”：依赖与重复
  • 依赖：上面的测例显然依赖于实现，改实现就必须要改测例，而这并不是我们想要的，我们的目标是编写有意义（能验证实现正确性）的测例，但是变更实现细节不需要修改测例，目前看来有点难；实际开发也是如此，如果代码依赖于某一组件的实现细节，那以后想要替换另一组件，就很麻烦；
  • 重复：If dependency is the problem, duplication is the symptom. 代码的重复往往起源于重复的逻辑，例如逻辑一样的表达式出现在多个地方；而对象（面向对象）天生就是用来把重复的逻辑抽象出来的，别辜负了对象；
  • 还好，在程序中，消除重复，就能消除依赖
• 找到重复，消除重复
  • 和实际代码的重复不太一样，不是基本相同的逻辑在重复；测例与实现的重复在于数据的重复，例如直接int amount= 10;和测例的测试数据是重复的
  • 书中的例子非常简单，但道理很深刻：TDD不是关于一些小的、简单的步骤，而是关于如何能够把难题拆分为小的、简单的步骤！
  • 其实当能够把每一步拆分得不能再小时，就表明对问题的理解达到了一定的程度，此时当然知道应该把问题拆分为何种粒度的子问题，保持思考！
• 让测例能够通过的合适的Dollar类代码，谁都会写，但是这个思考的过程却未必，而这正是践行TDD应该注意的地方！
• 完成上步后，就是时候考虑实现的优雅性了，将其也加入到todo list中吧！

• 一步一步来！