Case 3: Test is a customer requirement due quality complaint.

Scenario

• We are modifying an existent module, adding new features.
• The code is already designed time ago, without TDD.
• The modification is continuous and a little risky.

Then we receive a customer complaint, because the code didn´t work as expected. We didn´t fully understand the requirements and the project didn´t go forward.

Solution. Test as a contract.

Every new requirement, we include a function in a Test Codeunit. We pass all tests every modification and the most important: send a list of all the test to the customer as a contract.

Test code can be used as a contract: we tell the customer what we intend to do with a software, with the list of tests.

Then the customer can see that the errors are not program failures, they could be requirements misunderstanding. The feeling about our software quality seriously improved.

Conclusion

After this serie of posts we can conclude:

• We can use Test code without TDD because aren´t the same. Sometimes TDD scares programmers and begin to use test code could be the first step to embrace TDD later.

• Test code could be a product itself and then the customer is the programmer: we can make test code for save time and live better.

• Even when you aren´t designing under TDD, unit test could be an advantage.

• We can do test code to learn about the code of other people, and test subsequent versions: learning test.

• We can make code to prepare easier the environment for manual test, when this code saves us time.

• We can use the test code as a contract, that show what our code must do.