« LeSS - Tests unitaires » : différence entre les versions

De Wiki Agile
m Ajout encadré
 
(3 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 6 : Ligne 6 :
----
----
Traducteur : Nicolas Mereaux<br />
Traducteur : Nicolas Mereaux<br />
Relecteur : Fabrice Aimetti<br />
Date : 29/06/2022<br />
Date : 29/06/2022<br />
----
----
Ligne 133 : Ligne 134 :
Identique au schéma '''AAA''', le '''BDD''' utilise trois mots-clés différents pour spécifier chaque cas de test : '''Étant donné''', '''Lorsque''' et '''Alors'''. (Vous pouvez aussi utiliser '''Et''' comme mot-clé supplémentaire)
Identique au schéma '''AAA''', le '''BDD''' utilise trois mots-clés différents pour spécifier chaque cas de test : '''Étant donné''', '''Lorsque''' et '''Alors'''. (Vous pouvez aussi utiliser '''Et''' comme mot-clé supplémentaire)


<pre>
Given / Étant donné que la longueur du texte pour le retour à la ligne est défini à 10
Given / Étant donné que la longueur du texte pour le retour à la ligne est défini à 10
And / Et que le caractère '-' est utilisé comme connecteur entre deux mots
And / Et que le caractère '-' est utilisé comme connecteur entre deux mots
Ligne 143 : Ligne 145 :


=== La règle d’or du test unitaire ===
=== La règle d’or du test unitaire ===
In general, a good rule for unit test case is:


De manière générale, une bonne règle d’or pour des tests unitaires serait :
De manière générale, une bonne règle d’or pour des tests unitaires serait :


<blockquote>'''Each unit test case should be very limited in scope.'''
'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
<blockquote>'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
So that:


De telle manière que :
De telle manière que... :


* When the test fails, no debugging is needed to locate the problem.
* Tests are stable because dependencies are simple.
* Less duplication, easier to maintain.
* Lorsque le test échoue, qu’il ne soit pas nécessaire de faire du déboggage pour localiser le problème.
* Lorsque le test échoue, qu’il ne soit pas nécessaire de faire du déboggage pour localiser le problème.
* Les tests soient stables car les dépendances sont limitées.
* Les tests soient stables car les dépendances sont limitées.
* Il y ait moins de duplications, que ce soit plus facile à maintenir
* Il y ait moins de duplications, que ce soit plus facile à maintenir.
 
There is no secret to write good unit test. In order to write good unit test, you need to create easy-to-test design.


Il n’existe pas de secrets pour écrire un bon test unitaire. Afin d’écrire un bon test unitaire, vous devez créer une conception qui soit facile à tester.
Il n’existe pas de secrets pour écrire un bon test unitaire. Afin d’écrire un bon test unitaire, vous devez créer une conception qui soit facile à tester.