Les tests automatisés à eux seuls ne garantissent pas le bon fonctionnement de vos applications

Lorsque l’on commence à écrire des tests, nous avons souvent un sentiment de sécurité vis-à-vis du bon fonctionnement de nos applications. Une fonctionnalité a été conçue, une série de tests automatisés (qu’ils soient unitaires, fonctionnels, d’intégrations, parfois même en parallèle de tests manuels) a été mis en place. Tous les voyants sont au vert, vous êtes confiants, et pourtant, une fois en production… tout ne se passe pas comme attendu.

Il est indéniable qu’écrire des tests automatisés est essentiel lorsque l’on développe des projets informatiques. Ces derniers peuvent être joués à chaque modification d’un projet, participent à l’amélioration de la qualité et permettent de détecter des changements de comportement d’une application lors de modification dans le code.

Néanmoins, il est faux de penser qu’un projet avec des tests, indépendamment de leurs qualités, fonctionnera sans faille. La mise en place de tests ayant des limites.

Tout d’abord, le taux de couverture du code est un élément à prendre en compte lorsque l’on souhaite mesurer la qualité de nos tests. J’ai déjà évoqué la couverture de code dans ce blog, expliquant que c’est un indicateur à prendre avec précaution. Mais même avec la meilleure volonté du monde, il sera impossible de tester toutes les combinaisons possibles d’état de votre système.

Ensuite, quand on écrit des tests, de la même manière que lorsque l’on écrit du code applicatif, il est possible de faire des erreurs. Un test mal écrit, des jeux de données irréalistes, incomplets ou tout simplement biaisés peuvent aussi rendre nos tests imparfaits.

De plus, les tests sont généralement exécutés dans un environnement contrôlé ayant peu de dépendance avec l’extérieur. Les interactions avec des systèmes tiers sont généralement bouchonnées (mock en anglais). Cela crée un écart entre l’environnement de test et l’environnement réel d’exécution. Bien qu’il soit possible de créer des environnements au plus proches de la production, l’environnement et les conditions identiques de production ne pourront jamais être totalement rassemblés.

Et pour finir, si l’on considère que le développement d’une fonctionnalité résulte de la compréhension de cette dernière par le ou les développeurs qui l’implémente, alors une fonctionnalité mal comprise pourra entrainer l’écriture d’un test qui validera le fonctionnement compris sans pour autant répondre au besoin utilisateur.

Si les tests automatisés constituent un outil puissant, ils ne suffisent pas à garantir le bon fonctionnement d’une application. J’entends pourtant de nombreux développeurs garantir que leur développement est OK “parce qu’il est testé”. Certes les tests permettent de limiter les erreurs et les régressions, comme nous avons pu le voir, de nombreux facteurs sont à prendre en compte.