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

De Wiki Agile
← Modification précédente
VisuelWikicode
m Ajout encadré
 
(6 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 131 : Ligne 132 :
=== Développement piloté par le comportement (BDD) ===
=== Développement piloté par le comportement (BDD) ===


Similar to the '''AAA''' pattern, the '''BDD''' style uses three other keywords to specify each test case: '''Given''', '''When''' and '''Then'''. (You can also use '''And''' as another keyword.)
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 The Text Wrapper's Width Defined As 10
And Using '-' As Word Connector
When The Wrapper Wrap Text Length is Less Than 10
Then The Text Should Not Be Wrapped


<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
When / Lorsque la longueur du texte est inférieure à 10
When / Lorsque la longueur du texte est inférieure à 10
Then / Alors le texte ne devrait pas être retourné à la ligne</pre>
Then / Alors le texte ne devrait pas être retourné à la ligne</pre>
As you can see, “given-when-then” maps to “arrange-act-assert” pretty well. They both simply define a state transition of a Finite State Machine (FSM). You can find more on this in the [https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Uncle Bob’s article]. Some differences:


Comme vous pouvez le constater, le triptyque « étant donné - lorsque - alors » correspond plutôt bien avec le triptyque « Arrange - Act - Assert ». Ils définissent tous les deux un état transition d’une machine à état finie. Vous pouvez en savoir plus en consultant cet article d’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :
Comme vous pouvez le constater, le triptyque "étant donné - lorsque - alors" s'allie plutôt bien avec le triptyque "Arrange - Act - Assert". Ils définissent tous les deux un état transition d’une machine à état finie. Vous pouvez en savoir plus en consultant cet article d’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :
 
* Le BDD est davantage orienté "dehors vers dedans", cela veut dire qu’il met davantage l’accent sur le comportement externe
* BDD is more “outside-in”, which means that it emphasises more the external behaviour
* Avec le BDD, vous devez définir un '''langage spécifique au domaine''' pour écrire vos spécifications de tests. À cause de cela, vous aurez besoin généralement d’un ''framework'' supplémentaire. Par exemple, pour Python vous pourrez utilisez [https://pypi.org/project/behave/ behave].
* With BDD, you need to define a '''domain specific language''' to write your test specifications. Because of this, usually you’ll need a different framework. One example for Python is [http://pythonhosted.org/behave/ behave].
* Le BDD est davantage « dehors-dedans », cela veut dire qu’il met davantage l’accent sur le comportement externe
* Avec le BDD, vous devez définir un '''langage spécifique au domaine''' pour écrire vos spécifications de tests. À cause de cela, vous aurez besoin généralement d’un ''framework'' supplémentaire. Par exemple, pour Python vous pourrez utilisez [http://pythonhosted.org/behave/ behave].


=== 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.
Récupérée de "https://wikiagile.coach/LeSS_-_Tests_unitaires"