2. Les bonnes pratiques
Les pratiques suivantes vous aideront à rendre vos tests unitaires plus efficaces.
1. Écrivez des tests simples et lisibles
Les tests unitaires permettent de s'assurer que votre code fonctionne comme prévu. Cependant, vous ne pouvez savoir pourquoi une unité échoue que si vous écrivez des tests simples et lisibles. Il est plus facile d'écrire, de maintenir et de comprendre des cas de test simples. De plus, les tests simples sont plus faciles à refactoriser. Si le test est complexe et que vous devez refactoriser du code, les tests peuvent échouer.
Vous pouvez utiliser la structure AAA pour écrire des tests unitaires :
- Arrange : configurer le test en configurant le système testé et d'autres mécanismes;
- Act : appeler une action à effectuer pour tester l'unité;
- Assert : vérifier le résultat de l'opération effectuée pour vérifier qu'elle a fonctionné comme prévu.
2. Écrire des tests déterministes
Un test déterministe présente le même comportement tant que le code reste inchangé. Cela vous permet de comprendre le problème et de le résoudre. Ensuite, lorsque vous exécutez un autre test après avoir modifié le code, vous devriez voir des résultats différents qui réussissent ou échouent au test.
Un test non déterministe peut échouer ou réussir sans aucun changement de code. Il est difficile d'isoler le problème et de le résoudre, c'est pourquoi il est également appelé test instable. Vous pouvez éviter les tests non déterministes en isolant le cas de test, ce qui le rend complètement indépendant des autres cas.
3. Testez un scénario par test
Les tests manuels impliquent généralement de tester divers scénarios, par exemple, de vérifier qu'un certain bogue est résolu et que toutes les fonctionnalités associées fonctionnent comme prévu. Vous pouvez vérifier de nombreux types de tests et de variables, mais vous devez toujours vous assurer que chaque test unitaire couvre un scénario.
Couvrir un scénario par test unitaire permet d'isoler des parties de programme spécifiques contenant le problème lorsqu'un test échoue. Cependant, l'exécution d'un seul test pour couvrir plusieurs scénarios peut entraîner des incertitudes - une fois le test échoué, vous devez investir du temps pour identifier le problème.
4. Les tests unitaires doivent être automatisés
Vous devez mettre en place un processus automatisé pour les tests unitaires sur une base quotidienne ou horaire ou via un processus CI/CD. Configurez le processus pour vous assurer que tous les membres de l'équipe peuvent accéder aux rapports et les afficher. Cela permet de s'assurer que les équipes peuvent discuter des métriques pertinentes, y compris la couverture du code, le nombre d'exécutions de tests, la couverture du code modifié et les performances.
5. Écrire des tests isolés
Les tests unitaires isolés permettent de vérifier des composants spécifiques. Ce type de test est plus rapide à exécuter et offre plus de stabilité, garantissant que vous ne traitez qu'une seule logique à la fois. Vous pouvez créer des tests isolés à l'aide de substituts pour une classe réelle. Un substitut fournit une fausse version d'un composant, vous aidant à isoler son comportement dans le test unitaire.
6. Éviter l'interdépendance des tests
Les tests unitaires ne nécessitent pas une couverture de test à 100 %. Vous devez configurer moins de tests unitaires, mais de haute qualité, que de nombreux tests configurés uniquement pour atteindre la couverture de code nécessaire. Les tests unitaires visent à valider des unités de code individuelles, c'est pourquoi vous devez éviter l'interdépendance des tests.
La dépendance de test se produit lorsqu'un test unitaire dépend du résultat d'un autre. Lorsqu'un test échoue, toute la suite échoue également. Vous pouvez éviter ce problème en évitant l'interdépendance des tests dans les tests unitaires. Vous devez écrire des méthodes de test individuelles et indépendantes et placer les tests associés dans une seule classe de test.
7. Évitez les appels d'API actifs
Vous pouvez souvent rencontrer des appels d'API ou d'autres appels de service vers des bases de données que vous n'avez pas besoin d'inclure dans vos tests. Cependant, si les tests n'engagent pas ces appels, assurez-vous qu'ils sont inactifs pendant l'exécution des tests. Il est préférable de fournir des stubs d'API avec le comportement et les réponses attendus, en limitant les tests à des unités spécifiques.
8. Combiner les tests unitaires et d'intégration
La pyramide de test est un modèle populaire pour décrire la distribution souhaitée des ressources de test. Les tests deviennent généralement plus complexes et fragiles à mesure que vous montez dans la pyramide. Les tests du haut sont les plus difficiles à construire et les plus lents à exécuter et à déboguer, tandis que les tests de niveau inférieur sont plus rapides et plus simples à configurer et à déboguer. Les tests unitaires automatisés, représentant les niveaux les plus bas de la pyramide, devraient comprendre la plupart des tests.
Utilisez des tests unitaires pour valider tous les détails, y compris les conditions aux limites et les cas extrêmes. Utilisez les autres tests (tests de composants, d'interface utilisateur, fonctionnels et d'intégration) avec parcimonie pour évaluer le comportement global d'une API ou d'une application. Les tests manuels devraient constituer la plus petite proportion de votre pyramide de tests - ils sont utiles pour les tests d'investigation et d'acceptation des versions.
Le modèle pyramidal peut vous guider dans votre stratégie de test pour obtenir une couverture et une automatisation étendues des tests. Cela devrait vous aider à faire évoluer vos tests tout en minimisant les coûts liés à la création, à la maintenance et à l'exécution de vos suites de tests.
9. Assurez-vous que les tests unitaires sont reproductibles et évolutifs
Rendez vos tests unitaires répétables et évolutifs pour assurer le succès de votre stratégie de test. Établissez un ensemble organisé de pratiques pour vous assurer que tout le monde écrit les tests unitaires simultanément à l'écriture du code de l'application. Vous pouvez même écrire des tests avant d'écrire votre code d'application, comme la programmation basée sur le comportement ou les tests. Dans tous les cas, vous devez construire les tests en étroite collaboration avec le code de l'application.
Évaluez ensemble le code et les tests de l'application pendant le processus de révision du code. Les révisions fournissent des informations sur le code et son comportement, vous permettant d'améliorer les tests. L'écriture de tests avec le code est importante pour les corrections de bogues, pas seulement pour les mises à jour et les modifications planifiées. Il devrait toujours y avoir un test vérifiant chaque correction de bogue pour s'assurer qu'elle reste corrigée.
Adoptez une approche de tolérance zéro pour tester les échecs. Les tests sont inutiles si l'équipe ignore les résultats - un échec de test indique un problème réel, alertant l'équipe pour qu'elle le résolve immédiatement avant de perdre plus de temps sur du code bogué ou de le mettre en production.