Announcing the TDD Companion

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 of handbook or field guide. I believe anyone using TDD will find this helpful in advancing in their practice.

So today, I am announcing the release of “The TDD Companion.” It is available via Amazon’s Kindle Direct Publishing. Continue reading “Announcing the TDD Companion”

Specifying the Negative in TDD

Most requirements are statements of desired behavior. But there can be implications behind these requirements concerning behavior that is not desired.

For example, we might test-drive a value object that represents some domain information, and the requirement for it might include that the object must be “immutable.” The implication would be that the object has no mutator methods allowing the values contained to be altered.

How can we write a test that specifies that a method does not exist? Continue reading “Specifying the Negative in TDD”

TDD and the Magic Buttons

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 coverage.

But there is another difference. Continue reading “TDD and the Magic Buttons”

FLEX: A Pattern Language for Achieving Business Agility

Patterns are solutions to recurring problems within a context. A pattern language is a set of patterns that when combined solve a large problem. FLEX is a system that explicitly describes the process experts use to help an organization achieve business agility. These patterns include: Continue reading “FLEX: A Pattern Language for Achieving Business Agility”

TDD and Inflection Points

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 the developer to use the built-in Socket class that is part of .Net. Why would a developer create their own such entity? It makes sense to reuse what is well tested and proven over time to be effective. Continue reading “TDD and Inflection Points”

The Minimum Business Increment (MBI) Template

MBIs represent both the smallest amount of value that can be implemented and realized while also containing all of what’s needed for this realization. In other words, MBIs are small but sufficient. If it’s bigger than necessary, you will make flow harder to achieve. If it is insufficient, product may be built but it won’t be effectively realized.

Here is what an MBI must contain. Continue reading “The Minimum Business Increment (MBI) Template”

Keeping Tests Fast

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 keep tests fast. Continue reading “Keeping Tests Fast”

Make Tests Repeatable and Independent

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 be able to run tests frequently which in turn means that tests: Continue reading “Make Tests Repeatable and Independent”

TDD and Accuracy vs. Precision

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 level of precision required tells you how far to go in determining accuracy.

Here is an example. Continue reading “TDD and Accuracy vs. Precision”