For the last few month, I have been posting several times a week on what I hope are interesting topics relating to aspects of Test-Driven Development. Many people have commented positively on this work. I have just posted the sixtieth entry in this series and this seemed like enough content to gather into a sort … Continue reading "Announcing the TDD Companion"

Here is a bit of a thought experiment, first suggested to me by Eran Pe’er. Imagine there are two magic buttons in front of you. You know, without any doubt that if you press Button A then your code will suddenly have 90% code coverage. If you push Button B, you will have 80% code … Continue reading "TDD and the Magic Buttons"

Software is quite often implemented in the context of reusable frameworks and other preexisting, valuable entities. As our industry matures it becomes increasingly true that we don’t need to re-invent the wheel For example, if code is written that is required to send data over a TCP-IP connection in, say, C#, the tendency is for … Continue reading "TDD and Inflection Points"

TDD tests need to be run frequently. As an agile process, TDD needs to be responsive and flexible. Part of this is the ability to keep very short the feedback loop between tests and production. To run tests frequently without excessive cost requires that they must be executed quickly. Here are some things that help … Continue reading "Keeping Tests Fast"

In TDD, we want to run the tests frequently. When we do so, it shortens the pulse of our work, increasing velocity. Also, when a test unexpectedly fails, we know that it must be something we just did that produced this result. It becomes very easy to find the error. This means that we must … Continue reading "Make Tests Repeatable and Independent"

It is important that the system behaviors we create as developers are both accurate and precise. These are not the same. One can be: Accurate, but not precise, such as “Pi is a little over three.” Precise, but not accurate, such as “Pi is 5.393858303895.” They are not the same, but they are related. The … Continue reading "TDD and Accuracy vs. Precision"

Ideally in TDD, no more than one test is ever failing at any given point in time. This test represents the work that is about to be done but hasn’t yet. Also, this test should not spend a long time in the red. We want the suite to get back to “all green” as quickly … Continue reading "TDD: Keeping Tests Green"

TDD is a powerful way to develop new code. However, most organizations have significant existing code that was not developed this way. This “legacy code” is often difficult to test because it was not designed to be testable in the first place. In his excellent book, Working Effectively with Legacy Code, Michael Feathers outlines techniques … Continue reading "TDD and Legacy Code"

Refactoring is defined by Martin Fowler as “improving the design of existing code.” Refactoring stipulates two things: that behavior does not change, and that the design has been improved. While developers have been “cleaning up” their code from the very early days, Fowler made this a discipline that developers can collaborate within. He defined a … Continue reading "The Value of Refactoring Skills"

Abstract classes in languages like Java or C# serve two purposes: they create polymorphism in design, and they are a convenient place to put behavior that is common to all derived classes, avoiding redundancy. But if all behavior in TDD needs to be tested, and if instance behavior implemented in abstract classes cannot be tested … Continue reading "TDD: Testing Adapters for Abstract Classes"