Category: Test-Driven Development

Some studies show that TDD practitioners write more test cases than non-TDD practitioners. However, I do not believe that the test suites generated by TDD sessions are as good as the strong, systematic test suites we engineered in after applying different testing practices. The reasoning is simple: when doing TDD, we are not focused on…

TDD does not tell you how to start or what tests to write. This flexibility gave rise to various different schools of TDD. If you are familiar with TDD, you may have heard of the London school of TDD, mockist vs. classicist TDD, and outside-in TDD. This section summarizes their differences and points you to…

TDD is such a significant part of software development that it is no wonder researchers try to assess its effectiveness using scientific methods. Because so many people treat it as a silver bullet, I strongly believe that you should know what practitioners think, what I think, and what research currently knows about the subject. Research…

TDD works for most types of applications and domains. There are even about using it for embedded systems, where things are naturally more challenging, such as Grenning’s Test Driven Development for Embedded C (2011). If you can write automated tests for your application, you can do TDD.

Should we always use TDD? My answer is a pragmatic “no.” I do a lot of TDD, but I do not use TDD 100% of the time. It depends on how much I need to learn about the feature I am implementing: TDD creates opportunities for me to learn more about the code I am writing from…

Skeptical readers may be thinking, “I can get the same benefits without doing TDD. I can think more about my requirements, force myself to only implement what is needed, and consider the testability of my class from the beginning. I do not need to write tests for that!” That is true. But I appreciate TDD…

This section discusses the most common questions and discussions around TDD. Some developers love TDD and defend its use fiercely; others recommend not using it. As always, software engineering practices are not silver bullets. The reflections I share in this section are personal and not based on scientific evidence. The best way to see if…

Abstractly, the cycle we repeated in the previous section’s development process was as follows: This TDD process is also called the red-green-refactor cycle. Figure 8.1 shows a popular way to represent the TDD cycle. Figure 8.1 TDD, also known as the red-green-refactor cycle TDD practitioners say this approach can be very advantageous for the development process. Here…

For this example, we will create a program that converts Roman numerals to integers. Roman numerals represent numbers with seven symbols: To represent all possible numbers, the Romans combined the symbols, following these two rules: For instance, the number XV represents 15 (10 + 5), and the number XXIV represents 24 (10 + 10 –…

Software developers are pretty used to the traditional development process. First, they implement. Then, and only then, they test. But why not do it the other way around? In other words, why not write a test first and then implement the production code? We discuss this well-known approach: test-driven development (TDD). In a nutshell, TDD challenges our traditional…