From the article: >In most businesses, the only tests that have business value are those that are derived from business requirements. This 10000 times over.

From the article: >In most businesses, the only tests that have business value are those that are derived from business requirements. This 10000 times over. I write lots of tests for financial software. My tests are always longer than my code. However, my tests are always written to business/legal requirements and never to the code in a financial software context. Moreover I try very hard to ensure the tests can be run on production software safely, so we know for sure whether or not things are actually working as expected in the field. For application frameworks it is different. The tests are written to the specification, not to the code. But if I had a dollar for every time I have seen a test case that shouldn't be there, because it tested some non-requirement, or worse (some behavior of a dependency).....