Listen to this post
Developers often remark that the tests may contain the same algorithms that the production code does. This feels like redundancy and makes them wonder if TDD is promoting bad practices.
Example: A system that converts Fahrenheit to Celsius. The code would contain something like this:
return (F - 32) * 5/9;
The test might contain an assertion that looked something like this:
assertEquals((F - 32) * 5/9, result);
The same algorithm that is used to perform the conversion is used in the assertion that proves the code works properly. This seems like a redundancy but it is not. It is duplication.
- Duplication is “the same thing.”
- Redundancy is “things that change together.”
The algorithm in the test is included to specify. The algorithm in the production code is to implement. One could change independently from the other.
The clearest way to specify something is not always the most efficient way to implement it. If the developers decided that a better way to implement this behavior was:
return (F-32) / 1.8;
This would not require the test to change. Specifications always record domain knowledge. Implementation apply this knowledge. If they match this is a coincidence, not a problem.