Je suggère d'écrire une suite de tests complète dans les domaines où il est judicieux et pratique de le faire. Dans les domaines moins pratiques, rédigez des tests de santé mentale.
D'après mon expérience, les frais généraux d'un ensemble complet de cas de test en valent certainement la peine dans la plupart des cas, mais en réalité, la couverture du code a des rendements décroissants. À un moment donné, écrire plus de tests juste pour augmenter la couverture du code n'a tout simplement aucun sens.
Par exemple, selon votre langue / technologie, tester l'interface utilisateur peut ne pas être pratique ni même réalisable. De nombreux tests reposeront probablement sur ce que voit un utilisateur et ne peuvent pas être automatisés. Comment testeriez-vous qu'une méthode pour générer un captcha produise une image lisible par un humain par exemple?
Si un ensemble complet de tests va vous prendre trois jours pour écrire, la probabilité qu'un bug soit introduit dans ce composant sur la piste est très faible, et la fonction elle-même ne prend qu'une demi-heure à écrire, vous devriez probablement réfléchir sérieusement pour savoir si ce temps en vaut la peine. Peut-être que le simple fait d’écrire un test de santé mentale de base pour cette fonction apporterait une valeur?
Mon conseil général serait que vous testiez entièrement les composants là où les tests peuvent être écrits assez facilement. Cependant, s'il s'agit d'une zone très difficile à tester, tracez une ligne dans le sable et écrivez des tests qui testeront la zone à un niveau supérieur plutôt que de la tester complètement.
Dans l'exemple de captcha précédent, écrivez peut-être des tests qui vérifient qu'une image de la bonne taille et du bon format est renvoyée et qu'aucune exception n'est levée. Cela vous donne un certain niveau d'assurance sans aller trop loin.