Tester est-ce douter ?
Aujourd'hui on va parler d'un truc très connu des informaticiens mais encore trop peu connu en bio-informatique : les tests.
Cette pratique est pourtant conseillée dans le guide du bon broinformaticien . Alors, qu'est ce qu'un test ?
Un test désigne une procédure de vérification d'un système. Son objectif principal est d'identifier un nombre maximum de comportements problématiques du logiciel afin d'en augmenter la qualité (si les problèmes identifiés lors des tests sont corrigés). Merci Wikipédia !
Il existe 3 types de tests : les tests unitaires, les tests fonctionnels et les tests d'intégration.
Les tests fonctionnels correspondent la phase de tests de tout bon bioinformaticien à la fin du développement, qui consistent à vérifier que toute les fonctionnalités du programme demandé sont supportées.
Les tests d'intégration visent à s'assurer du bon fonctionnement de la mise en œuvre conjointe de plusieurs unités de programme.
Les tests unitaires visent à tester une unité de code. Cette définition ne nous aide pas beaucoup car il faut encore définir ce qu'est une unité de code ; selon les cas une unité de code peut signifier une classe, une fonction ou une instruction. Ce sont ces unités de code qui s'articule entre elle pour faire un code complexe. Dans cet article nous nous concentrerons sur les tests unitaires car ce sont les tests les plus simple d'utilisation et les plus performants pour garantir la qualité d'un programme.
À quoi sert un test unitaire ?
Un test unitaire sert à vérifier en fonction de certaines données fournies en entrée d’une unité de code que les données qui en sortent ou les actions qui en découlent sont conformes aux spécifications de cette unité.
Pourquoi tester ?
Mettons nous bien d'accord, il est possible de réaliser du très bon code sans test unitaire et il est aussi possible de réaliser du très mauvais code (peu efficace, laid) qui soit testé. Mais les tests unitaires sont la base du processus d'amélioration de la qualité du code.
Les tests permettent de vérifier la qualité du code de façon automatique. Ils aident aussi à améliorer la confiance dans la qualité du code développé par d'autre et donc le travail en équipe.
Contrairement aux tests empiriques (manuels) , les tests unitaires permettent de tester l'ensemble de son code en une seule commande, ce qui entraine un gain de robustesse et de temps de debug.
Grace aux tests automatisés il est aussi possible de connaître quel pourcentage de son code est testé. On parle de couverture de code. Cette couverture de code est un bon indice de la qualité du code et des tests.
Comment bien tester son code ?
Pour bien tester une unité de code il faut vérifier que dans un maximum de cas l'unité de code renvoie le résultat attendu. Pour cela il y a plusieurs bonnes pratiques à respecter :
- Il faut vérifier que le système testé est véritablement unitaire, c'est à dire qu'il n'est pas lié à d'autres unités de code.
- Si une classe est complexe à tester : il est temps de factoriser son code en plusieurs modules !
- Les tests doivent s’exécuter le plus rapidement possible pour être le plus facilement utilisables.
- Faites bien attention au code de vos tests pour qu'il soient facilement compréhensible.
- Ne testez qu’un comportement à la fois. Soyez raisonnable et gardez le test simple, lisible et concentré sur ce comportement.
Exemple de test en bioinformatique
Allons voir Antoine qui travaille avec son collègue Bernard sur un projet de développement de logiciel permettant d'afficher des fichiers VCF. Ils développent chacun un module : Antoine est chargé du parseur de fichier VCF et Bernard est chargé de l'interface graphique. Bernard utilise donc le module développé par Antoine. Avant d'utiliser le module d'Antoine, Bernard va pouvoir exécuter les tests ce qui lui permettra d'avoir confiance dans le code et dans le fonctionnement de l'API pour construire son interface graphique. Il est même possible qu'ils se soient mis d'accord sur les tests avant le début du développement, on parle dans ces cas la de Test Driven Development (TDD) car les tests entraînent le développement.
Durant le développement de l'interface ils pourront mettre en place des tests fonctionnels et des tests d'intégration.
Un exemple de test unitaire
Nous allons maintenant prendre un exemple de test unitaire en pseudo code
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[crayon-675881155082b393611627 ] def is_even(nbr): """ Cette fonction teste si un nombre est pair. """ return nbr % 2 == 0 class MyTest(): def test_is_even(self): assertTrue(is_even(8)) assertFalse(is_even(1)) assertFalse(is_even(-5)) assertEqual(is_even(0), True) |
Ce code va renvoyer
1 2 3 4 |
[crayon-6758811550830930341573 ]true true true true |
pour chacun des tests, ce qui montre que pour l'ensemble des cas testés la réponse est celle que l'on s'attendait à voir.
L'objectif des tests unitaires est de tester le fonctionnement normal d'une unité de code mais surtout de tester ses cas limites. Ce sont souvent les cas limites qui sont oubliés par les développeurs et provoquent des bugs.
Quelques outils pour faciliter les tests
Dans presque tout les langages il existe des librairies qui pourront vous faciliter l'écriture de tests unitaires. Pour le language python cet article est super bien : http://sametmax.com/un-gros-guide-bien-gras-sur-les-tests-unitaires-en-python-partie‑1/ . En R vous pourrez aller voire cet article : http://www.win-vector.com/blog/2019/03/unit-tests-in‑r/ .
Dans la suite de cet article je vais présenter quelques outils langage agnostique (indépendant du langage) pour faciliter les tests.
Balto
https://github.com/Lothiraldan/balto
Balto est un test runner qui permet de regrouper des outils test dans une interface graphique pratique.
Cypress
Cypress est un outil permettant de tester le front end d'applications web très facilement et de créer différents scenarii qui pourront ensuite être lancer automatiquement.
Conclusion
Tester n'améliore pas forcément la qualité du code et il est possible de faire du bon code sans tests mais les tests permettent de détecter plus facilement des erreurs dans le code, améliorent la confiance dans la qualité du code, rendent plus facile le travail collectif et aide à revenir plus facilement dans un projet laissé de coté . Donc n'hésitez plus, tester !
merci Yoann M, Zazo0o, et Azerin pour leur relecture.
Affiche d'illustration provenant de Commitstrip.com
Laisser un commentaire