Book Image

Test-Driven Java Development, Second Edition - Second Edition

By : Viktor Farcic, Alex Garcia
Book Image

Test-Driven Java Development, Second Edition - Second Edition

By: Viktor Farcic, Alex Garcia

Overview of this book

Test-driven development (TDD) is a development approach that relies on a test-first procedure that emphasizes writing a test before writing the necessary code, and then refactoring the code to optimize it.The value of performing TDD with Java, one of the longest established programming languages, is to improve the productivity of programmers and the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively. Starting with the basics of TDD and understanding why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.You'll be guided through setting up tools, frameworks, and the environment you need, and we will dive right into hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You'll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.With this book, you'll also discover how to design simple and easily maintainable code, work with mocks, utilize behavior-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
Table of Contents (18 chapters)
Title Page
Packt Upsell
Contributors
Preface
9
Refactoring Legacy Code – Making It Young Again
Index

Executable documentation


Another very useful aspect of TDD (and well-structured tests in general) is documentation. In most cases, it is much easier to find out what the code does by looking at tests than at the implementation itself. What is the purpose of some methods? Look at the tests associated with it. What is the desired functionality of some part of the application UI? Look at the tests associated with it. Documentation written in the form of tests is one of the pillars of TDD and deserves further explanation.

The main problem with (traditional) software documentation is that it is not up-to-date most of the time. As soon as some part of the code changes, the documentation stops reflecting the actual situation. This statement applies to almost any type of documentation, with requirements and test cases being the most affected.

The necessity to document code is often a sign that the code itself is not well-written. Moreover, no matter how hard we try, documentation inevitably gets outdated.

Developers shouldn't rely on system documentation because it is almost never up-to-date. Besides, no documentation can provide as detailed and up-to-date a description of the code as the code itself.

Using code as documentation does not exclude other types of documents. The key is to avoid duplication. If details of the system can be obtained by reading the code, other types of documentation can provide quick guidelines and a high-level overview. Non-code documentation should answer questions such as what the general purpose of the system is and what technologies are used by the system. In many cases, a simple README is enough to provide the quick start that developers need. Sections such as project description, environment setup, installation, and build and packaging instructions are very helpful for newcomers. From there on, code is the bible.

Implementation code provides all needed details while test code acts as the description of the intent behind the production code.

Note

Tests are executable documentation with TDD being the most common way to create and maintain it.

Assuming that some form of continuous integration (CI) is in use, if some part of the test documentation is incorrect, it will fail and be fixed soon afterwards. CI solves the problem of incorrect test documentation, but it does not ensure that all functionality is documented. For this reason (among many others), test documentation should be created in the TDD fashion. If all functionality is defined as tests before the implementation code is written and the execution of all tests is successful, then tests act as a complete and up-to-date information source that can be used by developers.

What should we do with the rest of the team? Testers, customers, managers, and other non-coders might not be able to obtain the necessary information from the production and test code.

As we saw earlier, two of the most common types of testing are black-box and white-box testing. This division is important since it also divides testers into those who do know how to write or at least read code (white-box testing) and those who don't (black-box testing). In some cases, testers can do both types. However, more often than not, they do not know how to code so the documentation that is usable by developers is not usable by them. If documentation needs to be decoupled from the code, unit tests are not a good match. That is one of the reasons why BDD came in to being.

Note

BDD can provide documentation necessary for non-coders, while still maintaining the advantages of TDD and automation.

Customers need to be able to define new functionality of the system, as well as to be able to get information about all the important aspects of the current system. That documentation should not be too technical (code is not an option), but it still must be always up-to-date. BDD narratives and scenarios are one of the best ways to provide this type of documentation. The ability to act as acceptance criteria (written before the code), be executed frequently (preferably on every commit), and be written in a natural language makes BDD stories not only always up-to-date, but usable by those who do not want to inspect the code.

Documentation is an integral part of the software. As with any other part of the code, it needs to be tested often so that we're sure that it is accurate and up-to-date.

Note

The only cost-effective way to have accurate and up-to-date information is to have executable documentation that can be integrated into your CI system.

TDD as a methodology is a good way to move along in this direction. On a low-level, unit tests are a best fit. On the other hand, BDD provides a good way to work on a functional level while maintaining understanding that is accomplished by using natural language.