Cet article fait partie d’une série dédiés aux tests unitaires et au TDD. L’introduction est ici.
2. L‘automatisation des tests s’applique uniquement sur les tests unitaires
Non! Le test automatisé est un processus: il décrit le fait d’avoir des tests qui sont évalués automatiquement durant votre process d’intégration ou de déploiement continu (CI, CI/CD). Cela couvre tous les types de tests que vous êtes en mesure d’automatiser: tests de comportement, tests de charge, tests de performance, tests d’intégration, tests du système, tests d’interface….
L’accent est porté sur les tests unitaires car ils sont rapides, (relativement) locaux et vous pouvez les exécuter en masse. Mais les tests de fonctionnalités, les tests de cas d’usage, les tests de performance,… doivent aussi faire part de vôtre chaîne de construction (CI). Vous devez réduire les tests manuels au maximum, car ils sont coûteux et lents à donner du retour.
Attention cependant, cela ne veut pas dire qu’il faut exclure tout test manuel; certain tests ne peuvent être exécutés que manuellement. Un exemple typique: les tests exploratoires, c’est à dire les tests qui servent à rechercher les bugs! Ils ne peuvent complètement s’automatiser, même si des outils de property based testing ou encore les frameworks de fuzzing s’approchent de ce type de recherche.
Il s’agit d’une activité où l’apport d’un testeur professionnel est incomparable.
Mon message est simple: automatiser tous types de tests.
Sans ouvrir le débat sur la pyramide des tests, débat important d’ailleurs (ici un avis éclairant de Thomas Pierrain), intégrez un maximum de tests automatisés dans vos chaînes de build. Pensez à utiliser différentes chaînes: nocturne (nigthly) ou hebdomadaire (weekly) pour ne pas trop ralentir la chaîne continue. Mais automatisez vos tests!
Et si on s’y mettait à fond: 100 % de coverage (la suite de cette série).
