Chapter 8 Test-Driven Development

Note  The source code of the completed Roman numerals kata, including its version history, can be found on GitHub at: https://github.com/Apress/ clean-cpp20.

Wait! There is still one really important step to be taken: we must separate the production code from the test code. We used the ArabicToRomanNumeralsConverterTestCase.cpp file all the time like our workbench, but now the time has come to remove the finished piece of work from the vise. In other words, the production code has now to be moved into a different, still-to-be created new file; but of course, the unit tests should still be able to test the code.

During this last refactoring step, some design decisions can be made. For example, does it remain with a free-standing conversion function, or should the conversion method and the array be wrapped into a new class? I would clearly favor the latter (embedding the code in a class) because it is toward an object-oriented design, and it is easier to hide implementation details with the help of encapsulation.

No matter how the production code will be provided and be integrated in its usage environment (this depends on the purpose), our gapless unit test coverage makes it unlikely that something will go wrong.

The Advantages of TDD

Test-driven development is a tool and technique for incremental design and development of a software component. That’s why the acronym TDD is also often referred to as “test-driven design.” It’s one way, of course not the only way, to think through your requirements or design before you write the production code.

The significant advantages of TDD are the following:

•\ TDD, if done right, forces you to take small steps when writing software. The approach ensures that you always have to write just a few lines of production code to reach the comfortable state

again where everything works. This also means that you are at most a few lines of code away from a situation where everything still worked. This is the main difference with the traditional approach of producing and changing a lot of production code beforehand, which goes hand in hand with the drawback that the software sometimes cannot be compiled and executed without errors for hours or days.

367

Chapter 8 Test-Driven Development

•\ TDD establishes a very fast feedback loop. Developers must always know if they are still working on a correct system. Therefore, it is important for them that they have a fast feedback loop to know in a split second that everything works correctly. Complex system and integration tests, especially if they are still carried out manually,

are not capable of this and are much too slow (remember the test pyramid in Chapter 2).

•\ Creating a unit test first helps a developer really consider what needs to be done. In other words, TDD ensures that code is not simply hacked down from the brain into the keyboard. That’s good, because code that was written that way is often error prone, difficult to read, and sometimes even superfluous. Many developers are usually going faster than their true capacity to deliver good work. TDD is a way to slow the developers down in a positive sense. Don’t worry, managers, it is good that your developers slow down, because this will soon be rewarded with a noticeable increase in quality and speed in the development process when the high test-coverage reveals its positive effect.

•\ With TDD, a gapless specification arises in the form of executable code. Specifications written in natural language with a text processing program of an Office suite, for example, are not executable—they are “dead artifacts.”

•\ The developer deals much more consciously and responsibly with dependencies. If another software component or even an external system (for example, a database) is required, this dependency can be defined due to an abstraction (interface) and replaced by a test double (mock object) for the test. The resulting software modules (e.g., classes) are smaller, loosely coupled, and contain only the code necessary to pass the tests.

•\ The emerging production code with TDD will have 100% unit test coverage by default. If TDD was performed correctly, there should not be a single line of production code that was not motivated by a previously written unit test.

368