TDD as a Sustainable Process: Introduction

This is my 48th post in this series on TDD. I wanted to bring some of this material together and engage with the notion of TDD as a sustainable process. In this posting, I will introduce the topic, and then cover some issues that pertain to sustainability and/or the seeming lack thereof. Continue reading “TDD as a Sustainable Process: Introduction”

TDD and Code Coverage Tools

In TDD and Code Coverage, we established that code coverage tools do not provide useful project metrics, in and of themselves. In TDD, we don’t use code coverage tools for this purpose because we don’t need to. If all production code is written to satisfy prewritten, failing tests, then by definition, all code is covered.

Still, we do have automated tools that can measure coverage. Are they useful to a TDD practitioner? Yes they are. Here are three things they are useful for. Continue reading “TDD and Code Coverage Tools”

TDD: Tests are Client Number 1

Part of the TDD process consists of writing failing tests before the code that will eventually make them pass. Test-first alone is not TDD per se, but it is a part of it.

When tests are written before production code, this has several beneficial effects. This comes from the fact that these tests have the same orientation toward the code that client code will have in the future. Tests are, essentially, the first clients of any behaviors they drive into the system. Continue reading “TDD: Tests are Client Number 1”

TDD and Dynamically-Typed/Interpreted Languages

One controversy in software development is the relative value of strong, static typing (as in compiled languages like Java) vs. dynamic typing (as seen in interpreted languages like JavaScript). No attempt will be made here to engage in this debate, but it is interesting to note the role of TDD in languages that are not statically typed. Continue reading “TDD and Dynamically-Typed/Interpreted Languages”

TDD and Naming Part 3: Customized Assertions

Unit testing frameworks, which are the most common tools used by developers to conduct TDD, come with pre-made assertions that can be used to verify the behaviors being specified. Typically, these include assertions such as:

“areEqual()” (value comparison)
“areSame()” (entity comparison)

Developers should not limit themselves to these pre-made assertions. Continue reading “TDD and Naming Part 3: Customized Assertions”

TDD and Naming: Part 2

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, converter.fahrenheitToCelsius(212));

However the use of these values directly in the assertion sidesteps an opportunity to express the meaning of those values in the specification. Continue reading “TDD and Naming: Part 2”