12 caractéristiques pour de bons tests automatisés

Il y a plusieurs raisons d'écrire des tests automatisés et leur écriture peut sembler relativement simple. Cependant, l'écriture de "bons" tests automatisés, est nettement plus difficile et nécessite une grande expérience et une formation.  

Dans cet article, j'ai recensé quelques objectifs (de haut niveau) qui doivent être vérifiés pour que les tests automatisés deviennent "bons". Lorsqu'ils sont atteints, on peut qualifier les tests automatisés définis comme "bons." 

Voici quelques objectifs de haut niveau qui pourraient s'appliquer : 
 

• Les tests doivent nous aider à améliorer la qualité. 
• Les tests doivent nous aider à comprendre le système. 
• Les tests doivent réduire (et non augmenter) le risque. 
• Les tests doivent être faciles à exécuter.
• Les tests doivent être faciles à écrire et à maintenir.
• Les tests doivent nécessiter une maintenance minimale au fur et à mesure que le système évolue autour d'eux. 

Les tests devraient nous aider à améliorer la qualité 

1. Test selon les spécifications

Si vous utilisez l'approche TDD (développement piloté par les tests) ou BDD (développement piloté par le comportement), les tests vous permettront de comprendre comment le système réagira. Le fait de réfléchir à différents scénarios pour les transformer en tests nous aide à identifier les zones où les exigences sont ambiguës ou contradictoires. Une telle analyse clarifie l'objectif de la spécification, ce qui conduit à une conception plus précise, améliorant ainsi la qualité du logiciel. 

2. Prévenir les anomalies

Les tests automatisés permettent de trouver les bugs, mais ce n'est pas l'objectif principal de l'automatisation des tests. Les tests automatisés visent à prévenir l'introduction de bugs. Pensez aux tests automatisés comme un rejet des défauts, ce qui empêche les bugs de revenir dans notre logiciel après nous être assurés qu'il en est exempté. Si nous disposons de tests de régression complets et de qualité, il n'y aura pas de bugs, car les tests signaleront les défauts avant même que nous ne vérifions notre code. 

3. Désignation des défauts

 Si les tests automatisés sont assez petits (c'est-à-dire que nous ne testons qu'un seul comportement dans chacun d'eux), nous serons en mesure d'identifier rapidement l'erreur, en fonction du test qui échoue. Mais pour y parvenir, nous devons écrire des tests pour tous les scénarios possibles afin de couvrir chaque unité du logiciel. Les tests ne doivent jamais contenir d'ambiguïtés. Il est donc crucial que les tests soient aussi petits et triviaux que possible (faible complexité, format cohérent et un seul comportement vérifié par test). 

Les tests doivent nous aider à comprendre le système 

4. Les tests comme documentation

 Les tests automatisés permettent de mettre en lumière la manière dont le code doit fonctionner. Ils montrent ce que devrait être le résultat (ils indiquent le résultat attendu d'un ou plusieurs scénarios). 

 Si nous voulons savoir comment le système se comporte, nous pouvons lancer le débogueur, exécuter un test et avancer étapes par étapes, à travers le code, pour voir comment il fonctionne. Les tests unitaires font figure de documentation pour le système. 

Les tests doivent réduire (et non augmenter) le risque 

5. Les tests comme filet de sécurité

La modification d'un code plus ancien est risquée car généralement, nous ne savons ce qui peut être cassé, et il est également difficile d'identifier si quelque chose a été cassé. Nous devons travailler rigoureusement et effectuer beaucoup d'analyses manuelles avant d'apporter des modifications. 

 Cependant, lorsque l'on travaille avec du code qui a une suite de tests automatisés, on peut travailler beaucoup plus rapidement. Les tests détecteront les effets de bords et nous indiqueront si nous avons cassé quelque chose. De cette façon, les tests automatisés agissent comme un filet de sécurité qui nous incite à oser prendre des risques.

6. Anticiper les risques 

Nous devons veiller à ne pas introduire de nouvelles problématiques dans le système suite à l'automatisation des tests. Gardez le script des tests séparés du code en production pour éviter de créer des dépendances spécifiques au test dans le système (particulièrement important pour le code des tests unitaires). Tout le code et toutes les bibliothèques spécifiques au test doivent être liés par le test et uniquement dans la version test et dans l'environnement de test. Les dépendances de test et le code de test ne doivent jamais se trouver dans le code final avant sa mise en production. 

Les tests doivent être faciles à exécuter 

Il existe quatre caractéristiques spécifiques qui rendent les tests automatisés faciles à exécuter. Grâce à ces quatre caractéristiques, il vous suffit de cliquer sur un bouton (ou mieux encore, de le déclencher automatiquement) pour obtenir le précieux retour d'information que les tests fournissent : 

•  Les tests doivent être entièrement automatisés afin d'être exécutés sans effort. 

• Les tests doivent être auto-évaluatifs afin de pouvoir détecter et signaler les erreurs sans inspection manuelle. 
• Les tests doivent être reproductibles afin d'être exécutés plusieurs fois avec les mêmes résultats. 
• Chaque test doit être indépendant afin qu'il puisse s'exécuter seul.
  
  

7. Des tests entièrement automatisés

Un test qui peut être exécuté sans aucune intervention manuelle est un test entièrement automatisé. La satisfaction de cette caractéristique est une condition préalable à la satisfaction des autres.

8. Auto-évaluation

Un test avec auto-évaluation permet de mettre en place les assertions qui vont vérifier que le résultat attendu est correct.  Le test nous avertit uniquement lorsque le résultat n'a pas été approuvé ; par conséquent, un test propre ne nécessite aucun effort manuel.  

9. Tests répétables

Un test reproductible peut être exécuté à l'infini et générer les mêmes résultats, sans intervention humaine ni analyse entre les exécutions.  

Les tests doivent être faciles à écrire et à maintenir 

Lorsque nous changeons le comportement d'une partie d'un système, nous devons nous attendre à ce qu'un petit nombre de tests soit affecté par nos modifications. L'un des avantages de l'automatisation des tests est de rendre les changements simples. Nous devrions donc toujours nous efforcer d'assurer que nos tests ne font pas le contraire (rendre les changements plus difficiles). Les tests doivent nécessiter un minimum de maintenance au fur et à mesure que le système évolue autour d'eux. 

10. Tests simples

Concentrez-vous sur les tests plutôt que sur la façon de les coder. Cela signifie que les tests doivent être simples/triviaux (faciles à lire, faciles à écrire et faciles à maintenir). Nous devons nous efforcer de vérifier une condition par test en créant une méthode de test distincte pour chaque combinaison unique de conditions. Chaque méthode de test doit tester le système par un seul chemin dans le système. 

11. Tests d'expression

Une bibliothèque de méthodes auxiliaires aidant à la mise en place d'un langage pour un domaine de test spécifique permet, à la personne qui rédige le script de test automatisé, d'exprimer son idée du test sans avoir à traduire sa pensée dans un code trop détaillé et complexe. 

12. Divisez les problèmes

Gardez le code des tests séparé du code en production (gardez la structure et la logique du code en production mais dans une structure parallèle). Chaque test doit se concentrer sur un seul problème pour éviter les tests compliqués et peu clairs. 

Pour résumé 

Il y a une différence entre un test et un bon test, mais il est souvent difficile de savoir comment définir un "bon" test. Dans cette liste de contrôle, j'ai partagé 12 caractéristiques pour de bonnes pratiques d'automatisation des tests, qui à leur tour se traduisent par des tests faciles à écrire et une maintenance adéquate - deux facteurs qui sont très importants pour un système.