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.
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.
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.
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”
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.
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 as possible.
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.