Wiki SIO Chaptal

Outils pour utilisateurs

Outils du site

Piste :
bloc3:testsunitaires

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
bloc3:testsunitaires [2023/04/03 16:22] – [Tests unitaires] adminbloc3: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).  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) ;   * 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 ;   * Plus un bogue est détecté tôt, plus facile sera sa correction et moins il coûtera ;
Ligne 29: Ligne 29:
  
 ===== Prudence ===== ===== Prudence =====
-**<color blue>Attention !</color>** (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. +**<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 : 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. 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+
  
bloc3/testsunitaires.1680531747.txt.gz · Dernière modification : 2023/04/03 16:22 de admin