Listen to this post
TDD is different from QA in many respects. Part of this involves the tests we choose to write. A case in point is the specification of public constants.
Example. When businesses buy assets, they can write-off (amortize) the value of those assets over time, as a taxation issue. The government will dictate how quickly a given asset can be amortized, called the “term.” If the term for writing-off an automobile was given to be five years by the IRS, developers would likely create a constant, AUTO_TERM or something similar, and assign it the value of 5. This constant would be used in any code that needed to perform a related calculation, rather than hard coding a literal “5” everywhere.
QA would find nothing to test here, it’s just a value. TDD on the other hand dictates that no code can be written unless a failing test is written first. That test would indicate that the constant exists, what its name is, where it is placed, and the current value. This puts the value into the specification, where it is preserved for the future, as part of a complete specification.
This also means that we can test-drive the change to this value when the government changes the law. This preserves our process as well as ensuring the accuracy of the change.