The Test-Driven Development (TDD) methodology was invented to improve the way we test the code we write, with the final goal of increasing the quality of systems being implemented. The basic idea is that the tests must be written before the code, and following the same requirements. In practice, adopting the TDD approach really caused an improvement in quality, even if in general the total development time also increased.
But in my opinion TDD is much more than a different way to test a system. I believe that it modifies completely the nature of the testing tasks. Actually, I think that this change is so profound that TDD was able to transform a hated activity in something that programmers can really enjoy.
In the past testing was something boring. Programmers didn’t like to spend much time testing their code; they preferred to delegate this task to the QA team. And it was considered normal if the testers in the QA team did find some bugs. After all, the software developers were too busy coding; they did not have time for all the repetitive actions related to testing. Most programmers felt that testing was an activity that did not require from them much creativity, neither used their special skills.
This reaction of programmers in relation to testing can be explained by concepts of Positive Psychology. According to the Flow theory, a person can only enjoy a task if there is a match between his abilities and the complexity of the task. As depicted in the graph on the right, when the person is skilled but the challenge is low the activity is considered boring. In contrast, when the person is skilled and the challenge is high, this can bring him to a state of arousal. In traditional testing methodologies there was a mismatch between the ability of software developers and the complexity of the testing task. The consequence is that programmers could not enjoy testing.
But TDD changes this picture because it transforms testing in just another type of programming task. When the software developers implement automated tests, they are actually writing code. Therefore, there is a match between their skills and the complexity of the testing task. Suddenly, testing becomes something that programmers can really enjoy doing.
This match between skills and complexity is in the root of any successful game. And TDD actually has some other characteristics that make it similar to games. This reminds me the concept of Gamification:
“Gamification is the use of game design techniques and mechanics to solve problems and engage audiences. Typically gamification applies to non-game applications and processes, in order to encourage people to adopt them. Gamification works by making technology more engaging, by encouraging users to engage in desired behaviors, by showing a path to mastery and autonomy, and by taking advantage of humans’ psychological predisposition to engage in gaming. The technique can encourage people to perform chores that they ordinarily consider boring.”
In TDD, using a framework such as xUnit makes the progress clearly measurable, like earning points. You start with a set of tests that are all “red” and gradually make them become “green”. It’s like a game: When all your tests are green, you win and this level of the game is over. Then you can move to a more advanced level, augmenting your challenge, either by adding new, more complex tests, or by performing some refactoring in the code that can potentially break some of the existing tests.
According to the book Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps, another very important characteristic of games is their immediate feedback:
“One of the most straightforward and important game mechanics, and one that is increasingly a cornerstone of the gamification movement, is feedback. Broadly defined, feedback is returning information to players and informing them of where they are at the present time, ideally against a continuum of progress.”
Every time you modify the code, you are actually taking the risk of breaking some tests. This generates the suspense of executing the tests after you made several changes in the code, to check the tests are still working. In practice, code refactoring can become an activity full of adrenaline. But the immediate feedback provided by automated tests allows you to take corrective actions in the case there were failures. At this stage, the coding-testing process can progress in fast iterations.
Sometimes you need to modify the tests because some requirement has changed. Of course in this case the right thing to do is to first change the tests and then the code. But I know that some programmers do exactly the opposite, and they first change the code and then check what tests were broken. This may be easier, because sometimes it is difficult to identify all the tests that are related to some specific requirement. Changing the code first is surely not the right thing to do, but it can be more fun.
If you still have any doubt that TDD is like a game, take a look in the TDGotchi application. I think it is a very original idea (but I must also say that I did not install it myself to check if it works).
So go on and have fun testing. It’s possible!