How Testers Should Approach TDD

The day before yesterday, I wrote about how Software Testing folks can contribute effectively to Ensemble Programming. The objective of Ensemble Programming is to brainstorm and ultimately write code. Test-Driven-Development (TDD) is a method that can be used for writing code. In this blog, let’s look at the role of testers in TDD.

There are several blogs about how to do Test-Driven-Development, and I am not going to go through how to do TDD. You could search for articles on how to do TDD. My objective with this blog is to highlight the pros and cons of TDD that are generally identified by the field, see if they are complete, augment with any additions, and then point to the best practices that the test practitioners can follow on participating and contributing in TDD.

Generally speaking, the highlighted pros of TDD are: fewer unit bugs, better design, better code coverage, easy refactoring, and easier change management. The highlighted cons of TDD are: it is perceived as time-consuming and counterproductive, difficulty in comprehending how things would work beforehand, developers’ preferences on their style of programming, test maintenance when things change (although this one is far easy to manage than the code without tests, in my opinion!)

One of the cons that’s nagging me as a tester that has not been generally identified by the field is that of specification-driven-tests. While code is driven by tests, tests are driven by specifications. There are two problems with specifications being documented as part of code. One major obvious problem is that specifications embedded in code are not easily readable and understandable by non-technical people like businesses. The other problem is that specifications can never be fully covered with all possible corner cases covered.

To address the first problem, BDD (behavior-driven-development) came into being, which gives a natural language friendly structure to write the specifications. Once the specifications are in place in a BDD file, TDD can take that file through a BDD processing framework and write the tests based on those specifications.

The second problem is tricky, although it is not any more tricky than having the specifications in a word document. Instead of having a document that in text specifies the system behavior, it might be valuable to have a machine-readable construct that can have the specifications. The problem of incompleteness of specifications is always there whether you write in a word document or you have it as BDD rules. When changes happen to requirements, or new requirements are added, since the BDD rules are linked to code, it’s easier to track and address those requirements through tests.

Now, let’s look at how testers can contribute to TDD process. I am not going into the BDD process in this blog, and saving it for another blog. So, what are the things that testers should watch out for?

• If TDD is done as it should be, i.e. is the development really test-driven?
• Are all the identified business requirements present in the code in form of tests?
• Do the tests align with requirements?
• Are tests written correctly with conditions to be satisfied?
• Are the design patterns specific to that programming language (if any) are followed?
• Are all design considerations being addressed (in addition to checking them at the first place in BDD itself)?
• During refactoring, is the code is optimized correctly and does not lead to issues?

With that list in hand, you are equipped to have a solid validation and verification contribution as a tester during TDD.

Hope that helps! Feel free to chat with me for your organisation’s needs for testers in TDD sessions.