Red/Green/Refactor: a pattern for clean code that works, Part II (How, Where, When)
On the first part of this post I spoke of the concept of TDD, as well as the reasons for using it. But what about the way to apply it, and more importantly, the context in which it should be used? This second part will address those subjects.
Example: Visual Studio Unit Testing Framework
In order to exemplify a kind of unit tests used in TDD in a graphical way, I chose to develop a quite simple Tic-Tac-Toe solution in C#, using Visual Studio. The following image shows three tests for the Square class, which can hold only circles, crosses or empty spaces (simulating a Tic-Tac-Toe square).
The use of this unit testing framework (Visual Studio Unit Testing Framework) is quite self-explaining. There is a test class that holds tests methods, which can be executed individually or all together. Each test method shown here has an Assert method in the end, which is one way of defining if the method passes or fails.
Note that these tests were written before actually coding anything to the actual class; so, when going to code the required functions, the API has already been defined by the tests, and it’s quite easy to know what to do.
Another important thing to mention is that tests shouldn’t have any kind of correlativeness between each other, since they should act as individual testing units. Here this is exemplified by the fact that the instance of the Square class can have different names among the tests, and they’ll still work perfectly.
TDD, ATDD and Scrum
Since a key matter in TDD based projects is to know how to divide and prioritize development tasks, TDD is more effective in agile environments such as Scrum. Practicing TDD is a good way to deliver constantly (see Frequent Delivery in our company mindsets), so TDD and Scrum do benefit from each other.
Furthermore, mainly because of the last point in the benefits section of the first part of this post, it’s extremely important for the customer to have an active and appropriate role in constantly defining the direction of the project (he is the one that will consume the product, hence it is wise for him/her to participate in the decision making). So that’s where Acceptance Test Driven Development (ATDD) comes into consideration. ATDD is in fact a really interesting subject which deserves a post on its own and more, but just to mention the concept, it’s a methodology that implies writing Acceptance Tests, that become the criteria that the customer defines for his business requisites.
It’s important, though, that the role of the customer and the developer doesn’t overlap each other: in other words, the customer shouldn’t define specific implementation details (the how) as requirements, because the developer usually knows more about it; and the developer, on the other hand, shouldn’t decide on strategic external features (the what), since the customer knows more about his business.
(Ideas for this section have been taken from ‘Diseño Agil con TDD‘, a must-read free online book for Spanish-speaking developers interested on the subject)
Conclusion
Test Driven Development is a powerful methodology, that can bring outstanding results, especially in large, complex projects. Its benefits are best shown not when using it on isolation, but when combining it with the appropriate resources and organization.
Again, if you have any thoughts about what I’ve said, don’t hesitate to comment here.
