Tests often establish example values used to compare the behavior of the system with the actual behavior indicated in the requirements. For example, if we had a system behavior that converted a temperature expressed in Fahrenheit to one expressed in Celsius, then the test that specified this might have an assertion along these lines: assertEquals(100, … Continue reading "TDD and Naming: Part 2"

TDD is not really a testing activity so much as it is about the creation of an executable specification. Because of this we value different things than testers might. Naming of tests, variables, and the use of well-named customized assertions are examples. Test names are sometimes provided by the tools we use. Many IDE’s will … Continue reading "TDD and Naming: Part 1"

TDD, when conducted as a specifying activity, is an aspect of Behavior-Driven Development (BDD). Behavior is what we specify and is what we “drive” into the system using tests. Therefore, when structuring the tests in TDD we can be guided by the language of BDD: Given, When, Then. Given the system is in a known … Continue reading "TDD and Test Anatomy"

Developers often remark that the tests may contain the same algorithms that the production code does. This feels like redundancy and makes them wonder if TDD is promoting bad practices. Example: A system that converts Fahrenheit to Celsius. The code would contain something like this: return (F - 32) * 5/9; The test might contain … Continue reading "TDD Replicating Algorithms"

When first adopting TDD, developers can run into some roadblocks that seem to indicate that TDD is a difficult process. In truth, some of these problems actually indicate faults in the system architecture. For example, developers will struggle to write unit tests of behavior that is embedded in a user interface, or in stored procedures … Continue reading "TDD and System Architecture"

When TDD was first suggested, there were many who were dubious about the wisdom of having developers write tests of their own code. Among the objections raised was that developers will slow down if you burden them with new tasks, namely writing the tests as well as the code. This seems logical. Give someone more … Continue reading "TDD Yields Velocity"

TDD is a process that provides constant confirmation to the development team. Writing the tests up-front confirms that there is sufficient understanding of requirements so that they can be expressed in the rigorous form of a unit test. Alternately, it reveals that this understanding has gaps and reveals questions that need to be answered. The … Continue reading "TDD Yields Confidence"

Exceptions in software represent a mechanism for raising an alarm when something goes wrong. They are used when there is a potential problem that cannot be detected by the compiler, linker, or other automated aspect of the development process, and thus may potentially make it into the released product. When an exception is declared in … Continue reading "Specifying Exceptions in TDD"

Specifying a workflow in #TDD means writing a test that says, “When entity A is called upon to accomplish a task, it must interact with entity B is the following way.” This is done when the interaction in question is part of a required workflow, and not simply an implementation decision that should be changeable. … Continue reading "Specifying Workflows in TDD, Part 2: How"

The term “workflow” in this sense is meant to indicate the way two system elements interact when performing a task. Often these interactions themselves are not exposed outside the system, and so only their resulting behavior should be tested. This is as true in TDD as it is in traditional testing. Most workflows are implementation … Continue reading "Specifying Workflows in TDD, Part 1: Why"