TDD depends on a strong connection between the automation of the test suite and the system itself. The suite should record the specification that is implemented in the system, and the connection allows this to be confirmed at any point. The problem is automated tests pass by default. So, if errors creep into the test … Continue reading "Sustainable TDD: Part 3"

Project managers have to balance resources. Spending them on one thing means not spending them on another. So, when the team adopts TDD, it is understandable that attention is paid to the level of resource needed to sustain it over time. It’s not uncommon for project managers to notice, as the project grows, that the … Continue reading "Sustainable TDD: Part 2"

TDD is typically part of an agile process. This means that we embrace change, that new requirements flow into the team’s work either on a time-boxed pulse, or through some kind of pull system (like Kanban). In TDD, a new requirement always starts out as a new, failing test or “specification.” We write the test … Continue reading "Sustainable TDD: Part 1"

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. There are those … Continue reading "TDD as a Sustainable Process: Introduction"

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. … Continue reading "TDD and Code Coverage Tools"

TDD often uses unit tests to drive behavior into the system. However, sometimes acceptance tests are used to do this. When these are automated, this can give us clues as to how to make our work in TDD more reusable. Tools like Fit, Specflow, and Cucumber are all designed to parse some non-technical artifact (such … Continue reading "TDD and Test Invariance"

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 … Continue reading "TDD: Tests are Client Number 1"

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 … Continue reading "TDD and Dynamically-Typed/Interpreted Languages"

In TDD, tests take actions such as Setup, Trigger, and Verify. Each of these pieces must successfully execute in order for the specification to be verified as accurate to the current behavior of the system. If there is an external dependency, the test can become vulnerable to a failure of that entity. For example, If … Continue reading "TDD and Guard 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) “isNotNull()” “contains()” Developers should not limit themselves to these pre-made assertions. The creation of … Continue reading "TDD and Naming Part 3: Customized Assertions"