Tests manuels et tests automatiques
Un test permet de valider qu'une fonctionnalité qui a été développée est opérationnelle. Cette fonctionnalité peut être un algorithme, un bout de code ou un logiciel complet.
Il existe plusieurs types de tests, que l’on peut répartir dans deux grandes catégories :
les tests manuels ;
et les tests automatiques.
Faire un test manuel est le premier réflexe qui vient après avoir réalisé un développement. On lance notre application, on clique et l'on tape pour vérifier qu'elle se comporte correctement.
Bien que ces tests soient indispensables, ils sont aussi très coûteux et très rébarbatifs. Faut-il passer plusieurs heures à retester toute une application après chaque petite correction ou une évolution ?
Tout retester ? À chaque petite modification ? Vraiment ? 🤔
N’importe quel développeur sera découragé dès le premier essai (moi le premier) !
C’est là qu’interviennent les tests automatiques. Ils sont faits pour nous faire gagner du temps en vérifiant automatiquement et très rapidement toutes les fonctionnalités de notre application. Contrairement aux tests manuels, il n'y a plus aucun problème de temps ou de paresse pour les exécuter, et pas de risque d’erreur humaine.
Là, c’est une machine qui travaille, et en général, les machines protestent rarement quand on leur donne du travail à faire, aussi rébarbatif soit-il... 😉
Et dans ce cours, nous allons nous concentrer sur ces tests automatiques !
Alors quels sont les types de tests qui existent ?
Le Comité Français des Tests Logiciels identifie quatre niveaux de tests :
Les tests unitaires permettent de tester un composant, ou un bout de code, isolé de ses dépendances.
Les tests d'intégration permettent de vérifier que tous les bouts de code isolés fonctionnent bien ensemble.
Les tests système permettent de tester l’application tout entière.
Et enfin, les tests d'acceptation permettent de s’assurer que l’application répond bien au besoin fonctionnel.
Les tests unitaires et les tests d’intégration
Les tests unitaires sont les plus simples à développer et doivent pouvoir s’exécuter très rapidement afin d’avoir un retour sur la réussite de son test le plus rapidement possible. L’objectif est de savoir tout de suite si une modification ou un remaniement du code a des impacts sur le reste des fonctionnalités.
Les tests d’intégration, a contrario, sont là pour vérifier justement que tout fonctionne bien ensemble. Ils sont en général plus longs à exécuter et permettent de tester les dépendances que l’on est capable de maîtriser, par exemple une base de données ou des fichiers. Par contre, il faudra toujours bouchonner les dépendances sur lesquelles nous n’avons pas la main, par exemple faire appel à un web service tiers qui nous donne la météo.
Les tests système et d’acceptation vont encore plus loin et permettent de s’assurer que l’application complète et déployée dans les mêmes conditions qu’en production fonctionne comme on le souhaite.
Alors, pourquoi ne fait-on pas des tests d’acceptation seulement, puisque ce sont eux qui se rapprochent le plus de ce que feront les utilisateurs de notre application ? 🧐
La pyramide des tests
Le problème, c’est qu’écrire des tests automatisés, c’est écrire du code. Cela prend du temps et comme pour n’importe quel code, il peut y avoir des bugs et des besoins d’évolution et de maintenance.
Et, comme vous vous en doutez, plus le test est complexe, plus il sera long à développer et plus il sera compliqué à maintenir. Cela a donc un fort impact sur le coût d’un test.
Mike Cohn, un des inventeurs de la méthode agile Scrum, a synthétisé ces éléments sur un schéma, que l’on nomme habituellement la pyramide des tests :
Il y met en relation le coût d’un test par rapport à son utilité. En observant ce schéma, on en arrive à la conclusion qu’il faut trouver un équilibre entre les différents types de tests et qu’il vaut mieux avoir beaucoup de tests unitaires et moins de tests de bout en bout.
À noter que ce n'est pas non plus une vérité absolue et que cela dépend du type d'application que vous réalisez. N'hésitez pas à confronter le type de test à ce que vous souhaitez vraiment tester.
Nous allons nous concentrer dans ce cours sur les tests unitaires et les tests d'intégration qui sont les tests que vous écrirez le plus souvent dans votre vie passionnante de développeur. 😉
