When we are doing TDD, we are doing four things at the same time: Analyzing the problem, Analyzing the solution, Coding the solution, and testing the solution. For that reason, sometimes it’s complicated to perform it. But doing that will give us some of the really great benefits that we'll discuss in this article, remember the mantra:
- Software written using TDD looked different from software that was written without: thanks to TDD, your code is testable, modular, loosely coupled, exhibited high cohesion, had a good separation of concerns, and implemented information hiding. So TDD not only evaluated the behavior of software but increased the quality of its design.
- Something important to highlight about TDD is that it’s not just doing unit testing, integration testing, or functional testing. TDD is a design technique used to build software. Unit testing is just a tool, and there is not only one but also functional tests, integration tests, e2e tests, etc.
- It’s strongly recommended to start with functional tests (black box testing approach instead of white box). So basically, it gives us the opportunity to think and design the business rules instead of just focusing on small and independent parts.
- The difference between doing testing and TDD is the time that you create your test. If you create a test first, you are doing TDD. Otherwise, you are doing testing.
- The GREEN step should be as easy as possible for their implementation. Don’t think of future cases. Just implement the solution for the cases that you need to address now. It’s really important to point out this because something that should be careful is not spending too much time on each step (RED, GREEN, YELLOW).
- If step one (RED) is not failing, it’s because of two possible: A) we have a duplicated test, so we don’t need it. B) In the previous iteration in the refactoring step (YELLOW), we overthink the solution of the previous test, which means that we are not following TDD in the right way. Again, focus on one problem at a time.
- When you are performing TDD, another really strong benefit is immediate feedback, which allows us to speed up the building of the solution to the problem and also catch the bug earlier. That way, it will help us to catch errors almost immediately. So, in a really early stage of our development cycle (the earlier catch error, the cheaper it is).
- Another benefit to having immediate feedback is detecting smells in a premature way, like the following: Imagine that we are spending a lot of time building just one test. It’s a smell that probably the design of our solution is not right, so maybe we should address the solution in a different way.
- It’s important to highlight that TDD helps us to build our software in an iterative and incremental way. This means it’s similar to how humans learn any knowledge; it’s just a natural process.
- The reason is that the test should throw an error in the beginning (before starting to create the implementation). It’s related to detecting if we have duplicated tests, so in that case, we don’t need it. In the previous iteration in the refactoring step (YELLOW), we overthink the solution of the previous test, which means that we are not following TDD in the right way. Again, focus on one problem at a time.
- Building our software in an iterative way gives us a complete history of the evolution of our software. It not only works as a test regression but also helps us to document our system.
- Performing TDD force to deliver a simple, decouple, easier to extend, easier to maintain, and to scale design. So, it mainly helps us to implement in the right way the separation of concern and single responsibility principles.
- It reduces the fear of refactoring your code; it allows us to start working in an iterative, incremental, and progressive way. It allows us to increase the quality of the code in a really safe way.
- One of the consequences of following TDD is that we decrease the coupling of your system and maximize cohesion.
- Just keep in mind, following TDD, it’s not a warranty that you will have a good design, but, in most cases, your code will be less coupled.
- Keep the focus on building the minimal and fundamental part of the code needed, so in that way, it helps us not to have code that really isn’t needed. Because we are working in an incremental way (avoid the common example: “Maybe this part of code will help me in some moment, I will keep it”).
- Another really interesting point is that you don’t need to think more than using the case at the time, so avoid a lot of overthinking. The more complicated the problem, the easier it will be to do TDD because you don’t need to think about all the possible problems or combinations of our problems in each situation; each test should be careful about each specific situation.
- In the middle-long term, your velocity to add new features or change existing ones will be faster. “If you want to deliver faster, do it right”.
- You have free Regression testing!
- One of the benefits of TDD is its high coverage. As a consequence of that, we will reduce from 40% to 80% fewer bugs in production.
- As much as we perform the Unit test as a part of a traditional TDD, the faster you will code. It has a curve; at the beginning, you will spend more time on a task, but then, as you gain more experience working in that way, you will realize that you are building much faster than before. (It takes years of practice to achieve that, but it is worth it).
- As we know, the longest part of the life of an application is the containment part. So, our app will be cheaper in the mid-long term than working without TDD because there will be less effort/price to maintain that.
- TDD was not a new idea when Kent Beck described it in his book in the late of 1990. Alan Perlis had described something similar at the NATO Software Engineering Conference in 1968, but Beck introduced the concept and described it in significantly more depth.
I want to clarify that TDD is more about designing a way to build our software, to perform our workflow of the job, and the reason for our problem first. Unit tests are not a fundamental part of TDD methodology; it’s just a mechanism that gives us several benefits at their level.
