Test Driven Development (TDD) is a Software design and implementation technique included in Extreme Programming (XP). TDD is centered on three fundamentals pillars:
- Implementation of only the functionality the client needs and no more
- Minimization of number of bugs on production phase
- Modular software development, highly reusable and prepared for changes
When we start to read about TDD we think that it is a good technique to help us having a good test coverage on our Code, but it is actually a design tool that transforms a “programmer” into a “developer”. TDD is the answer for the big questions about:
How can I do it? Where should I start? How do I know what should be implemented and what not? How to write a code that can be modified without breaking existing functionality?
It is not about writing a lot of tests, but designing appropriately according to the requirements.
Instead of thinking on how to implement tasks, we should think on examples to eliminate the ambiguity created by the natural language (human language). Until now, we were used to think that the tasks or Use Cases were the smaller work units for developing a code. With TDD we try to translate the Use Case or the task on X examples, until the number of examples are enough to describe the task without misunderstandings.
In other software methodologies, we think first on defining the architecture. For instance, we evaluate whether we should use a Facade pattern or Singleton or DTOs, etc. What if it turns out that we do not need that? How is it going to take to realize it? How much money are we going to waste? By using, TDD we let that the implementation of little examples, on constant iterations, direct the architecture we need, emerge. This does not mean that we should not be concerned about the technical characteristics of the application. Logically we should know if the development is for a mobile, web, desktop, or hybrid platform because we need to choose the correct development tools. TDD produces an architecture that emerges from the non-ambiguity of the automated tests.
The benefits of the TDD are:
- Software quality increases.
- We get highly reusable code.
- Work in teams is easier.
- We can trust our colleagues even if they have less experience.
- It Multiplies the communication between the team members.
- People in charge of quality assurance acquire a more intelligent and interesting role.
- Writing the example (test) before the code forces us to write the minimum of functionality needed, avoiding over-designing.
- When we inspect a project developed using TDD, we realize that the tests are the best technical documentation to understand what is the objective of every piece of code.
But this is not a magic wand and it will not give the same result to an expert software architect than to a junior programmer. Nevertheless, it is useful for everyone. For the architect it is a guide to clarify business domains on each test and it allows him to trust his team regardless of their experience. Sometimes, distrustful architects look very carefully at the team’s code before any commit. This becomes a “bottle neck” because there are several people waiting for the boss (the architect) to give the ok to the code and the architect’s work is accumulated. When the boss knows his team does TDD correctly he can build trust more easily. For a junior programmer, it tells which is the next step. It guides on the implementation of the task assigned to him.
When the team uses TDD communication flows and people become more active.
TDD algorithm
TDD’s essence is simple but put it into practice correctly is a matter of training. TDD algorithm has three steps:
- Write the specification of the requirement (the example, the test)
- Implement the code according to the example
- Refactor to eliminate duplicity and to make improvements
Write the specification first
Once we know which is the requirement, we express it in the form of code. We can use, for example, a xUnit framework. How do we Write a test for a code that does not yet exist? We can answer with another question. Is it not possible to write a specification before implementing it? For example, JSRs (Java Specification Request) are written for third parties to implement. So, it’s possible. A test is not initially a test but an example or a specification. The word ‘specification’ could have the connotation that is fixed but this is not true. A test can be modified. To write it, we should think first about how we want the API of the SUT (subject under test) to be. But only a little part, a well-defined behavior of the SUT and only one. We should try to imagine how would it be the SUT code if it was already implemented and how would we verify that it does what we asked to do. The difference with the JSR is that we don’t design all the specifications before implementing each one but we go one by one following each of the three steps of the algorithm.
Implement the code that makes the example work
Having the example written, we code the minimum so that the test passes. Typically, the minimum code is the one with the less number of characters because minimum means the one that less time it took us to write it. It does not matter if the code looks ugly, we are going to correct that on the next step and on the next iterations. On this step, the most important thing is not implement anything more than what is strictly mandatory to meet the current specification. It looks easy, but it’s not. We will realize that we always write more code than we need. If we are well concentrated, we will have some doubts about the SUT behavior on the different conditional flows. We will be tempted to write the code to manage them at this moment and only paying attention will help us to avoid that impulse and write the questions on another place to transform them on specifications for other iterations.
Refactoring
Refactoring does not mean to rewrite the code; rewriting is more general than refactoring. Refactoring menas to modify the design without modifying the behavior. In this third step of TDD algorithm, we look into the code (including the test) trying to find duplicate lines and we remove them by refactoring. Also, we check that the code satisfies certain design principles and we refactor to satisfy them.
In addition to duplicity, we can also try to make the code clearer and easier to maintain.
The key of a good refactoring is to do it on little steps. We make a change, execute all the test and if all keep working, we make another little change.
And TDD works on big projects? A big project is the grouping of little sub-projects and is the moment to apply the idea of “divide and conquer”. The size of the project is not related to the applicability of TDD. The key is to know how to divide and prioritize. Scrum helps us to manage the product backlog. For this reason people combine XP with Scrum.
Conclusion
TDD requires a change in mentality for the developers. It’s not easy to achieve acceptance by development teams. Sometimes the teams don’t see TDD as something that can bring improvements to their jobs. It’s important to have balanced teams that make the most of this technology and get quality results in their work.
We usually see that TDD is explained using examples of projects that are starting. This way of presenting the methodology has given rise to one of the main objections or limitations found to TDD, which is the use of it in projects already started. A way to apply TDD on this kind of projects is to start using it with the new functionality and then start adding it to the changes suffered by the existing code.
TDD can be applied to any type of project, regardless of size, since a large project must be subdivided to achieve success. The methodology must be used for what it was created, this is, a methodology for software design and programming and not to use it for software testing once it was developed.
In conclusion, TDD has been in the software industry for more than 10 years and its main application nowadays is in projects with agile methodologies such as XP or Scrum, but you can see that it is possible to apply it in other projects and not only in new projects.
Would you like to know more? Do you need our help? Contact Us!
www.quadiontech.com
Test Driven Design (TDD) was originally published in Quadion Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.
