Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloc3:testsunitaires [2023/04/03 16:20] – [Typologie des tests] admin
+++ bloc3:testsunitaires [2023/04/04 11:40] (Version actuelle) – [Exemples d’environnements de tests unitaires] admin
@@ Ligne 3: / Ligne 3: @@
 Le concept de tests n'est pas une nouveauté. Depuis toujours, tester le code fait partie intégrante de l'activité quotidienne d'un développeur. **Attention** ! On parle bien ici de tests (au sens d’une démarche dédiée à amener un code vers un niveau de qualité optimal) par opposition à de la mise au point (au sens d’une pratique destinée à rendre un code simplement opérant).
-Dans un certain nombre de contextes de développement aujourd’hui, cette activité se place au cœur du processus de conception (Méthodes Agiles ou encore TDD). Il y a plusieurs raisons à cela :
+Dans un certain nombre de contextes de développement aujourd’hui, cette activité se place au cœur du processus de conception (**[[https://fr.wikipedia.org/wiki/M%C3%A9thode_agile|Méthodes Agiles]]** ou encore **[[https://fr.wikipedia.org/wiki/Test_driven_development|TDD]]**). Il y a plusieurs raisons à cela :
   * Concevoir le test d'un service, avant même d'avoir codé le service à tester : favorise la modularité (petites unités à tester) et la concision (le développeur n'implémente que l'essentiel) ;
   * Plus un bogue est détecté tôt, plus facile sera sa correction et moins il coûtera ;
@@ Ligne 26: / Ligne 26: @@
 Un test unitaire est un programme qui vérifie le bon fonctionnement d’une unité fonctionnelle élémentaire (une procédure, une fonction ou une méthode) au travers de situations déduites des spécifications de l’unité testée : à partir de données particulières en entrée, le test sollicite l’unité et confronte les données réellement obtenues avec celles théoriquement attendues. Il en déduit alors un état de succès ou d'échec.
-La « couverture des tests » désigne le rapport entre le nombre de situations testées et le nombre de situations possibles. Par principe, la couverture des tests n'est jamais complète car il n’est pas raisonnable, et souvent pas envisageable, d’imaginer tester toutes les situations possibles. On se « contentera » donc de recenser les cas de tests les plus remarquables.
+La **couverture des tests** désigne le rapport entre le nombre de situations testées et le nombre de situations possibles. Par principe, la couverture des tests n'est jamais complète car il n’est pas raisonnable, et souvent pas envisageable, d’imaginer tester toutes les situations possibles. On se « contentera » donc de recenser les cas de tests les plus remarquables.
- Prudence
-Attention ! (Cf. http://fr.wikipedia.org/wiki/Test_%28informatique%29) : La réussite des tests ne permet évidemment pas de conclure au bon fonctionnement du logiciel.
+===== Prudence =====
+**<color blue>Attention !</color>**  La réussite des tests ne permet évidemment pas de conclure au bon fonctionnement du logiciel ([[http://fr.wikipedia.org/wiki/Test_%28informatique%29|Test informatique]]).
 On essaye cependant, avec rigueur mais assez empiriquement, de faire en sorte que si un bogue est présent, le test le mette en évidence, notamment en exigeant une bonne couverture des tests :
+  * Couverture en __points de programme__ : chaque point de programme doit avoir été testé au moins une fois ;
-•	Couverture en points de programme : chaque point de programme doit avoir été testé au moins une fois ;
+  * Couverture en __chemins de programme__ : chaque séquence de points de programme possible dans une exécution doit avoir été testée au moins une fois (impossible en général) ;
-•	Couverture en chemins de programme : chaque séquence de points de programme possible dans une exécution doit avoir été testée au moins une fois (impossible en général) ;
+  * Couverture __fonctionnelle__ : chaque fonctionnalité doit être vérifiée par au moins un cas de test.
-•	Couverture fonctionnelle : chaque fonctionnalité doit être vérifiée par au moins un cas de test.
 Selon la complexité du logiciel, des séquences de vérification globale peuvent s'avérer nécessaires. Celles-ci mettent en jeu la maîtrise d'ouvrage et toutes les composantes du projet, au-delà du logiciel lui-même (processus, organisation, formation, accompagnement du changement) : réception, qualification, certification, homologation, simulation, VABF (vérification d'aptitude au bon fonctionnement) … les termes varient selon les contextes.
-Exemples d’environnements de tests unitaires
+===== Exemples d’environnements de tests unitaires =====
+  * PHP : PHPUnit, Atoum, SimpleTest
-PHP : PHPUnit, Atoum, SimpleTest
+  * JAVA : [[bloc3:junit|JUnit]]
-JAVA : JUnit
+  * .NET : NUnit
-.NET : NUnit