Is TDD for you?
Test Driven Development (TDD) is a software development approach that is associated with clean code concepts. Those who write code in a traditional way may like to try to do it the TDD way and experiment if that provides them with any benefits.
Although the concept is simple and straightforward; it comes with the penalties of having to maintain your unit tests as part of the source code base. The unit tests themselves are not part of the shippable production code; but they are part of the source code repositories and need to be maintained frequently.
Before attempting to answer the question yourselves; you need to understand the concept of TDD. The simple process goes like this:
First you write a failing unit test code that requires satisfaction of a single atomic simple requirement such as calling a function that has not yet been created or validating a single input not being null value.
Next you are requested to write the minimal code - and we mean it the least instructions or lines of code - that makes the unit test succeeds (i.e. goes from red to green).
Once the unit test goes green; you need to look back at the whole accumulative production and test unit source code and see if you need to refactor and clean up. And this is an incremental step that should not be postponed to a later stage.
Clean coders usually use the three hats concept to declare the three basic stages of TDD: Red hat for writing a failing unit test, green one to make it succeed, and a blue one to refactor code if needed.
The above process repeats until a complete user or customer story is completed in either a Scrum Agile or Extreme Programming (XP) SDLC process.
The benefits that you will immediately noticed include the following:
- Unite test if properly injected shall cover almost the whole in hand use case scenario for both happy case and exceptional. This relieves test engineers from conducting manual tests at that level
- The production code is brought to the minimal KLOCs units needed to satisfy a workable customer story
- When new code is added to either alter a completed customer story or to add a new scenario; any breaking to the current code base will be immediately noticed by a failure of an already succeeding set of unit tests
- The unit tests serve as self documentation of business and technical requirements for the system
But is there any drawbacks for this process? The main drawback is that you need to always maintain your test cases while adding new scenarios, customer stories, or features; a thing that might become hectic and of a valuable cost when the code base grows larger and larger.
Is TDD for you? Experiment and see for yourself.