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:26] – [Prudence] 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 38: Ligne 38:
 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 
- +  * JAVA : [[bloc3:junit|JUnit]] 
-PHP : PHPUnit, Atoum, SimpleTest +  * .NET : NUnit
-JAVA : JUnit +
-.NET : NUnit+
  
bloc3/testsunitaires.1680531960.txt.gz · Dernière modification : 2023/04/03 16:26 de admin