Best practive for finding unit-tests? (if not developing test-first)

Question

At some point you have to decide which parts of your programm you want to cover with unit-tests.

If you're developing test-first then you're off the hook as you already have your test cases. Congratulations. If you're not so lucky (that's the case in our project) you have to decide for which parts of your programm you are going to write unit-tests.

Is there a good and methodic approach to decide what to cover with unitt-tests? Ecspecially one that is more specific than asking yourself what should I test here??

Answer 1

IMHO:

1. Everything in the original specification.
2. Everything that is relied upon to work forever.
3. Everything that you found broken and had to fix.

Not terribly helpful I am sure - but realistic.

Unit tests should cover as much as you have time for and then cover everything you did not have time to test the last time you worked on them.

What approach can be used to find chunks of work worth testing?

There are many:

• Whenever you find a bug, fix it and create a test that will ensure it never returns.