Author: haroonkhan
-
Does TDD work for all types of applications and domains?
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.
-
TDD 100% of the time?
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…
-
To TDD or not to TDD?
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…
-
TDD in the real world
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…
-
Reflecting on our first TDD experience
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…
-
Our first TDD session
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 –…
-
Introduction
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…
-
The Hexagonal Architecture and mocks as a design technique
Now that you know about the Hexagonal Architecture and the idea of ports and adapters, we can talk about mocks as a design technique. In a nutshell, whenever mockists develop a feature (or a domain object) and notice that they need something from another place, they let a port emerge. As we saw, the port…
-
Static methods, singletons, and testability
As we have seen, static methods adversely affect testability. Therefore, a good rule of thumb is to avoid creating static methods whenever possible. Exceptions to this rule are utility methods, which are often not mocked. If your system has to depend on a specific static method, perhaps because it comes with the framework your software…
-
Private methods and testability
A common question among developers is whether to test private methods. In principle, testers should test private methods only through their public methods. However, testers often feel the urge to test a particular private method in isolation. A common reason for this feeling is the lack of cohesion or the complexity of the private method.…