TW洞见 | 用TDD影响设计

在听过Martin Fowler、Kent Beck和DHH关于TDD的讨论以后，我想也把我关于TDD的想法记录下来——我为什么要遵从它，以及为什么我会发现它做为一种思考过程，在解决设计问题的时候特别有帮助。

直到我完全理解了用户案例（也即测试案例）之前，我无法设计或者编写生产代码。因此，我从思考用户案例开始，我为它编写代码。现在这样的思考方式本身对我来说，就是“测试驱动”的。并且基于已经确认的测试案例，我开始仔细考虑我的设计。我需要在运行代码前编写测试代码；为了确认我的代码能工作，我需要测试它。

While building test cases on the whiteboard or as pending test cases, I identify the design patterns to be implemented. Now should I start writing my test and code, without design pattern abstraction and refactor to the desired design pattern, or jump directly into defining classes and tests using my desired design pattern? Both approaches work for me. I like to start small, so I write my first test case and write code to implement that. However, sometimes I like thinking of design upfront to avoid immediate test cases implementation rework, but will not code for it. And so I draft my test cases with the design already in mind.

Lots of times I don’t have a clue, can’t think of abstraction and design upfront, in that case starting flat is good. And after implementation of a few test cases, my code starts shaping up and I get more insight to find better abstractions. Sometimes it is difficult to write tests without even having a ‘code structure skeleton’ in place. Even though I feel drafting a ‘code structure skeleton’ is OK at times, you can avoid it by avoiding doing a 1-1 mapping of your “test class” with your “code class”. TDD also helps me with good naming, because I started with the use-case. Since I code the client (call) first, that helps me in naming it from the usage perspective and not from implementation perspective.

To get the most out of TDD, don’t be too dogmatic about its implementation; instead use it as a technique to influence the way you design. For instance, TDD is really helpful in identifying smells in design. I have seen code all test driven, but full of switch case constructs without abstractions, which entirely misses the point of TDD. In my view, if I am following TDD, it does not mean my design is good, but rather I should use it as a technique to drive my design. Here are few obvious TDD test smells that help me identify bad design,

• Difficulty in writing tests: Especially when there are too many dependencies that require too much setup code. In the Rails world for example - ‘Fat Controllers’ without services or helper classes.
• Excess tests for a single unit: This happens when classes have too much responsibility. In the Rails world, the example would be ‘Fat Models’.
• Excess assertions: This happens when one method is doing too many things or tests are written at the wrong level. One test is trying to test too many things at once.
• Excess tests for a component: While the individual tests are very fast, it takes very long to run all tests. This may be an architectural smell of a monolithic application. Break it down into small components. On my last project we had the UI as a separate repo with only Views (templates), CSS and JS, including unit tests for Views and JavaScript.
• Cascading effects of code modification on unrelated tests: This is the case when a change in code, leads to changes required in other unrelated tests. This happens due to unnecessary mocking or testing at the wrong level. For example a change in the code for the model requires changes in the controller tests without any of the controller code having changed.

Practicing TDD also helps me with slicing and dicing stories, because TDD is a technique that helps one think of the minimal use-case that should be implemented to get started.

What are your thoughts on using TDD?