Un excellent document qui parle de tests unitaires et tests fonctionnels.

En règle général, il vaut mieux se concentrer sur les tests fonctionnels plutôt que les tests unitaires car ces derniers sont très couteux à maintenir, notamment leur de remaniement de l'architecture du code.

Quelques extraits:

Few developers admit that they do only random or partial testing and many will tell you that they do
complete testing for some assumed vision of complete. Such visions include notions such as: “Every line of code has been reached,” which, from the perspective of theory of computation, is pure nonsense in terms of knowing whether the code does what it should.

Tests should be designed with great care. Business
people, rather than programmers, should design most functional tests. Unit tests should be limited to those that can be held up against some “third-party” success criteria

The purpose of testing is to create information about your program. (Testing does not increase
quality; programming and design do. Testing just provides the insights that the team lacked to do a correct design and implementation.)

Don’t underestimate the intelligence of your people, but don’t underestimate the collective stupidity of many people working together in a complex domain.