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

De Wiki Agile
← Modification précédente
VisuelWikicode
m Ajout encadré
 
(23 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 47 : Ligne 48 :
Il est légitime de vous poser cette question. Pourquoi n’utilisons-nous tout simplement pas de manière rigoureuse des tests fonctionnels automatisés ou des tests systèmes automatisés pour protéger le programme ?
Il est légitime de vous poser cette question. Pourquoi n’utilisons-nous tout simplement pas de manière rigoureuse des tests fonctionnels automatisés ou des tests systèmes automatisés pour protéger le programme ?


'''Total cost of ownership''' – Unit test is based on the abstraction level of the programming language. It’s just some code exercising other code. It doesn’t need to run in the same environment as the production. For compiled programming language, it doesn’t even need to use the same compiler as the production. The creating and running cost of unit test is very low. If designed properly, the cost of maintaining is also very low. You may not get the same level of confidence from one successful unit test case as you can get from a functional test. You will need many small unit test cases to get approximately the same level of confidence. But the cost of these small unit test cases is still much lower than owning a few functional test cases.
'''Le coût total de possession''' — Le test unitaire se base sur le niveau d’abstraction du langage de programmation utilisé. Il s’agit juste d’un bout de code qui va tester un autre bout de code. Il n’a pas besoin de s’exécuter sur le même environnement que celui en production. Pour un langage compilé, il n’est même pas nécessaire d’utiliser le même compilateur que celui en production. Le coût de la création et l’exécution est très faible. S’il est conçu correctement, le coût de maintenance est aussi très faible. Vous pouvez ne pas avoir le même niveau de confiance pour un cas de test unitaire qui s’est exécuté avec succès que pour un cas de test fonctionnel. Vous pourriez avoir besoin de plusieurs cas de test unitaire pour avoir le même niveau de confiance. Mais le coût de tous ces petits cas de test unitaire restent malgré tout plus faible que celui de plusieurs cas de test fonctionnel.


'''Le coût total de possession''' — Le test unitaire se base sur le niveau d’abstraction du langage de programmation utilisé. Il s’agit juste d’un bout de code qui va s’exécuter sur un autre bout de code. Il n’a pas besoin de s’exécuter sur le même environnement que celui en production. Pour un langage compilé, il n’est même pas nécessaire d’utiliser le même compilateur que celui en production. Le coût de la création et l’exécution est très faible. S’il est conçu correctement, le coût de maintenance est aussi très faible. Vous pouvez ne pas avoir le même niveau de confiance pour un cas de test unitaire qui s’est exécuté avec succès que pour un cas de test fonctionnel. Vous pourriez avoir besoin de plusieurs cas de test unitaire pour avoir le même niveau de confiance. Malgré tout, le coût de tous ces petits cas de test unitaire restent tout de même plus faible que celui de plusieurs cas de test fonctionnel.
Si le code source n'a bénéficié d'aucun test unitaire depuis les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux origines principales :


If a software code base hasn’t got any unit test for the past 2 years, there will be extra cost for applying unit test to this code base. The cost comes mostly from two sources:
# Le coût d’application d’un ''framework'' de test sur le code du projet. C'est relativement plus facile pour des langages de programmation dynamique comme Python, Ruby ou Javascript. De manière générale, c’est aussi relativement trivial pour des projets Java ou C#. Cela peut être toutefois assez compliqué pour un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# Le code source existant n’est pas testable car le code a été conçu au départ sans prendre en compte l’aspect testabilité. Appliquer des tests unitaires à ce type de code source implique souvent de devoir améliorer la conception existante. Mener cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a potentiellement un autre coût qui est lié à l'introduction de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires pour un code source existant se doit d’être combinée avec d’autres types de travaux qui nécessiteront des modifications dans le code sous test — autrement dit lorsque le moment sera venu de changer ce morceau de code.


Si la base de code n’a eu aucun test unitaire dans les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux sources principales :
'''Qualité interne vs. Qualité Externe''' — Les tests automatisés de haut niveau comme les tests fonctionnels et les tests systèmes contrôlent la qualité externe du logiciel. La qualité externe permet de connaître le niveau de fonctionnement du logiciel par rapport aux exigences. En effet, les tests unitaires ne sont pas aussi efficaces que les tests fonctionnels pour protéger la qualité externe. Par contre, les tests unitaires s’assurent de la qualité interne du logiciel. La qualité interne veut dire ici la testabilité du code et permet de savoir jusqu’à quel niveau le code est protégé. Une conception testable est synonyme en général de bonne conception. D’autres types de tests automatisés ne remplissent pas ce rôle aussi bien que les tests unitaires.


# The cost of applying a test framework to the code project. This is relatively easier for dynamic programming languages like Python, Ruby or Javascript. Usually, it’s also trivial for Java and C# project. It can be quite tricky for C/C++ project. No matter easy or hard, this is just one-time investment.
# Le coût d’application d’un ''framework'' de test sur le code du projet. Cela est relativement plus facile pour des langages de programmation dynamique comme Python, Ruby ou Javascript. De manière générale, c’est aussi relativement trivial dans des projets Java ou C#. Cela peut être toutefois assez compliqué dans un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# The existing code base is not testable. The code was designed without considering the testability. Applying unit test to this kind of code base often involves improving the current design. Doing so doesn’t only increase the cost of creating test, but also has potential cost of introducing new bugs by changing the design. So applying unit test to existing code base should be combined with other works that need the change from the code under test – when you have to change that piece of code regardless.
# La base de code existante n’est pas testable car le code a été conçu au départ sans prendre en compte l’aspect testabilité. Appliquer des tests unitaires à ce type de base de code implique souvent de devoir améliorer la conception existante. Faire cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a aussi potentiellement un coût d’introduire de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires à une base de code existante se doit d’être combinée avec d’autres types de travaux qui nécessiteront des modifications dans le code sous test — autrement dit lorsque le moment sera venu de changer ce morceau de code.


'''Internal Quality vs. External Quality''' – High level automated test like functional test and system test checks the external quality of the software. External quality means how well the software is functioning according to the requirement. Unit test is not as effective as the functional test in protecting the external quality. On the other hand, unit test ensures some of the internal qualities of the software. Internal quality here means the testability of the code and how well the code is protected. A testable design is in general a good design. Other levels of automated test cannot serve this purpose as well as unit test.
'''Qualité du ''feedback''''' — Après avoir passé un test fonctionnel, vous pouvez être confiant vis-à-vis de la fonctionnalité testée. Mais lorsque vous vous apercevez que le test échoue, vous devez généralement faire du déboggage pour trouver ce qui est erroné. Les tests unitaires peuvent vous donner une information plus précise sur ce qui fonctionne ou ne fonctionne pas.


'''Qualité interne vs. qualité externe''' — Les tests automatisés de haut niveau comme les tests fonctionnels et les tests systèmes contrôlent la qualité externe du logiciel. La qualité externe permet de savoir le niveau de fonctionnement du logiciel par rapport aux exigences. En effet, les tests unitaires ne sont pas aussi efficaces que les tests fonctionnels pour protéger la qualité externe. Par contre, les tests unitaires s’assurent de la qualité interne du logiciel. La qualité interne veut dire ici testabilité du code et permet de savoir jusqu’à quel niveau le code est protégé. Une conception testable est synonyme en général de bonne conception. D’autres types de tests automatisés ne remplissent pas ce rôle aussi bien que les tests unitaires.
Les tests unitaires étant sur le même niveau d’abstraction que le langage de programmation employé, tout devrait s’exécuter au niveau du micro-processeur et de la mémoire lors de l’exécution du test unitaire. Et comme chaque cas de test devrait être de petite taille, il devrait donc s’exécuter très rapidement. Ainsi, vous devriez être en mesure d’exécuter plusieurs centaines de tests unitaires en quelques secondes. En prenant en compte le temps de compilation ou de préparation, l’ensemble du processus d’exécution d’un test unitaire devrait prendre moins d’une minute.


'''Quality of feedback''' When you passed a functional test, you could be very confident about the functionality you just tested. But when you found it fail, usually you need to do some debugging to see what is wrong. Unit test might be able to give you more precise information about what is working and what is broken.
Les tests unitaires devraient aussi être répétables. Si rien ne change d’une fois sur l’autre, l’exécution d’un test unitaire devrait toujours retourner le même résultat.


'''Qualité du ''feedback''''' Après avoir passé un test fonctionnel, vous pouvez être confiant vis-à-vis de la fonctionnalité testée. Mais lorsque vous vous apercevez que le test échoue, vous devez généralement faire du déboggage pour trouver ce qui est erroné. Les tests unitaires peuvent vous donner une information plus précise sur ce qui fonctionne ou ne fonctionne pas.
Si un test unitaire est très rapide et répétable, les développeurs peuvent l’exécuter aussi souvent qu’ils le veulent, par exemple toutes les deux minutes. Le test unitaire fournira en permanence aux développeurs des retours d’informations liés à la qualité. Cela permettra ainsi aux développeurs d’avancer à un rythme régulier et de se focaliser sur des choses plus importantes plutôt que de passer trop d’énergie sur des choses triviales.
 
Unit test is on the abstraction level of the programming language. When running unit test, everything should happen just within the CPU and memory. And each test case should be small. Therefore, it should run very fast. Typically, you should be able to run hundreds of unit tests within a few seconds. Including the compiling or other preparation time, the whole process of running unit test should take less than 1 minute.
 
Les tests unitaires étant sur le même niveau d’abstraction que le langage de programmation employé, tout devrait s’exécuter au niveau du micro-processeur et de la mémoire lors de l’exécution du test unitaire. Et comme chaque cas de test devrait être de petite taille, il devrait donc s’exécuter très rapidement. Ainsi, vous devriez être en mesure d’exécuter plusieurs centaines de tests unitaires en quelques secondes. Cela comprend le temps de compilation ou de préparation, l’ensemble du processus d’exécution d’un test unitaire devrait prendre moins d’une minute.
 
Unit test should also be repeatable. If nothing changes, unit test runs should always return the same result.
 
Les tests unitaires devraient aussi être répétables. Si rien ne change d’une fois sur l’autre, l’exécution d’un test unitaire devrait retourner toujours le même résultat.
 
If the unit test is very fast and repeatable, programmers can run it as often as they want, e.g. every a few minutes. The unit test will continuously provide quality feedback to the programmer. So that the programmer can go with a steady progress and focus on more important things rather than spending too much energy on trivial issues.
 
Si un test unitaire est très rapide et répétable, les développeurs peuvent l’exécuter aussi souvent qu’ils le veulent, par exemple toutes les quelques minutes. Le test unitaire fournira en permanence aux développeurs des retours d’informations liés à la qualité. Cela permettra ainsi aux développeurs d’avancer à un rythme régulier et de se focaliser sur des choses plus importantes plutôt que de passer trop d’énergie sur des choses triviales.
 
[[File:https://less.works/img/technical-excellence/xtest_levels.png.pagespeed.ic.-xbOy_tP-P.png]]


[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png|border|link=|700px]]
[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png|border|link=|700px]]
A reasonable automated test structure should be like a pyramid. At the bottom are a lot of unit test cases. In the middle are much fewer integration level test cases. On the top, there are even fewer functional/system level tests.


Une structure de test automatisé acceptable devrait ressembler à une pyramide. À la base de la pyramide, il y a un grand nombre de cas de tests unitaires. Au milieu, des cas de tests d’intégration en moins grand nombre. En haut, seulement quelques cas de tests fonctionnels ou systèmes.
Une structure de test automatisé acceptable devrait ressembler à une pyramide. À la base de la pyramide, il y a un grand nombre de cas de tests unitaires. Au milieu, des cas de tests d’intégration en moins grand nombre. En haut, seulement quelques cas de tests fonctionnels ou systèmes.
== Common Misconceptions of Unit Test ==


== Idées fausses à propos du test unitaire ==
== Idées fausses à propos du test unitaire ==
=== Unit test is not as important as the production code ===


=== Le test unitaire n’est pas aussi vital que le code en production ===
=== Le test unitaire n’est pas aussi vital que le code en production ===


It is true that in the end, it’s production code that makes the product. But most software products have evolutionary life cycles. The code is not static. It changes over time. Code without unit test does not have the necessary protection when being changed. Unit test also contains important information that is not included in the production code.
Il est vrai qu’en fin de compte, c’est le code en production qui donne vraiment vie au produit. Mais la plupart des produits logiciels ont des cycles de vie évolutif. Le code n’est pas statique. Il change avec le temps. Un code sans test unitaire n’est pas suffisamment protégé lorsqu’une modification est faite. Le test unitaire contient aussi des informations importantes qui ne sont pas présentes dans le code en production.
 
Il est vrai qu’en fin de compte, c’est le code en production qui donne vraiment vie au produit. Mais la plupart des produits logiciels ont des cycles de vie évolutif. Le code n’est pas statique. Il change avec le temps. Du code sans test unitaire n’est suffisamment protégé lorsqu’une modification est faite. Le test unitaire contient aussi des informations importantes qui ne sont pas présentes dans le code en production.
 
So unit test is just as important as the production code. They should be '''in the same SCM repository'''. They should follow the same coding standard as the production code.


Par conséquent le test unitaire est tout aussi important que le code en production. Il devrait être stocké '''dans le même dépôt de gestion du code source'''. Le test unitaire devrait d’ailleurs suivre les mêmes conventions de codage que le code en production.
Par conséquent le test unitaire est tout aussi important que le code en production. Il devrait être stocké '''dans le même dépôt de gestion du code source'''. Le test unitaire devrait d’ailleurs suivre les mêmes conventions de codage que le code en production.
=== Unit Test is done by testing engineers ===


=== Le test unitaire est fait par des ingénieurs tests ===
=== Le test unitaire est fait par des ingénieurs tests ===
The purpose of unit test is not for finding bugs. Technically, it ''checks'' rather than ''tests'' if the code under test has implemented the behaviour intended by the programmer who designed it. So the reasonable choice is just let the same programmer writes both the test and the code under test.


L’objectif du test unitaire n’est pas de trouver des anomalies. Techniquement, il ''vérifie'' plutôt que ''teste'' si le code sous test a implémenté le comportement voulu par le développeur qui l’a conçu. Donc le choix logique est de simplement laisser la même personne écrire à la fois le test et le code sous test.
L’objectif du test unitaire n’est pas de trouver des anomalies. Techniquement, il ''vérifie'' plutôt que ''teste'' si le code sous test a implémenté le comportement voulu par le développeur qui l’a conçu. Donc le choix logique est de simplement laisser la même personne écrire à la fois le test et le code sous test.
It’s also encouraged to have two or more people pair up to do the programming together. They write the unit test and the code under test together. There are many fun ways of ''pair-programming''. You may find more information in the Test-Driven Development section.


Il est aussi encouragé d’avoir deux ou plusieurs personnes travaillant de concert pour programmer à la fois le test et le code sous test. Il existe plusieurs manières sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.
Il est aussi encouragé d’avoir deux ou plusieurs personnes travaillant de concert pour programmer à la fois le test et le code sous test. Il existe plusieurs manières sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.
=== You can write unit test without changing the code under test ===


=== Vous pouvez écrire des tests unitaires sans changer le code sous test. ===
=== Vous pouvez écrire des tests unitaires sans changer le code sous test. ===
This is often not true. If the code doesn’t have good testability, you might still be able to write unit test for it technically. But the unit test written for non-testable code is usually very hard to maintain and understand. Therefore, it doesn’t make much sense to have it.


Ce n’est pas toujours le cas. Si le code n’a pas une bonne testabilité, vous pourriez tout de même être capable techniquement d’écrire le test unitaire qui va avec. Mais un test unitaire qui a été écrit pour un code non-testable est généralement très difficile à maintenir et à comprendre. Par conséquent, il n’y a pas vraiment de raison d’en avoir un.
Ce n’est pas toujours le cas. Si le code n’a pas une bonne testabilité, vous pourriez tout de même être capable techniquement d’écrire le test unitaire qui va avec. Mais un test unitaire qui a été écrit pour un code non-testable est généralement très difficile à maintenir et à comprendre. Par conséquent, il n’y a pas vraiment de raison d’en avoir un.


'''The secret of unit test is not about writing test, but writing testable code under test.''' We want testable code and easy test, which is a win-win. We don’t want non-testable code and hard-to-maintain code, which is a lose-lose.
'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire un code testable sous test.''' Nous voulons du code testable et facile à tester, ce qui s’avère une démarche gagnant-gagnant. Nous ne voulons pas de code non-testable et difficile à maintenir, ce qui serait une démarche perdant-perdant.
 
'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire du code testable sous test.''' Nous voulons du code testable et facile à tester, ce qui s’avère une démarche gagnant-gagnant. Nous ne voulons pas de code non-testable et difficile à maintenir, ce qui serait une démarche perdant-perdant.
 
=== I can add unit test later ===


=== Je peux ajouter les tests unitaires plus tard ===
=== Je peux ajouter les tests unitaires plus tard ===
Well, try asking the rock climbers to set their anchors later.


Eh bien, essayez donc de demander à des grimpeurs de mettre leurs pitons plus tard.
Eh bien, essayez donc de demander à des grimpeurs de mettre leurs pitons plus tard.


[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]
[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=|500px]]
 
[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=]]
 
== Good Unit Test Patterns ==


== Schéma pour de bons tests unitaires ==
== Schéma pour de bons tests unitaires ==
=== No news is good news ===


=== Pas de nouvelles, bonnes nouvelles ===
=== Pas de nouvelles, bonnes nouvelles ===


If the test passes, it should just print OK (and perhaps some dots to show the progress). No other information.
Si le test passe, il devrait afficher seulement OK (voire quelques points pour afficher son avancement). Aucune autre information n'est nécessaire.
 
Si le test passe, il devrait afficher seulement OK (voire quelques points pour afficher son avancement). Aucune autre information nécessaire.


[[Image:unit_test_success.png|unit_test_success.png|border|link=]]
[[Image:unit_test_success.png|unit_test_success.png|border|link=|800px]]


Rule of thumb:
Règle empirique :


En règle générale :
Aucune intervention humaine ne devrait être nécessaire pour préparer l’exécution du test, exécuter les cas de tests ou en vérifier les résultats.


<blockquote>No human intervention should be needed to get ready for the test, running the test cases or checking the result.
Et lorsqu’un test unitaire échoue, il devrait nous fournir toutes les informations nécessaires. L’objectif est de limiter la durée pendant laquelle vous êtes occupé à débogguer le code concerné.
</blockquote>
<blockquote>Aucune intervention humaine ne devrait être nécessaire pour préparer l’exécution du test, exécuter les cas de tests ou en vérifier les résultats.
</blockquote>
And when it fails, it should provide precise information. The goal is to limit the amount of time you spend on debugging when the test fails.<br />


[[Image:342xNxunit_test_fail.png|342xNxunit_test_fail.png|border|link=]]
[[Image:342xNxunit_test_fail.png|342xNxunit_test_fail.png|border|link=]]
Et lorsqu’un test unitaire échoue, il devrait nous fournir toutes les informations nécessaires. L’objectif est de limiter la durée pendant laquelle vous êtes occupés à débogguer le code concerné.


=== Arranger, Agir, Auditer (''Arrange'', ''Act'', ''Assert'') ===
=== Arranger, Agir, Auditer (''Arrange'', ''Act'', ''Assert'') ===


A good pattern to follow in a unit test is “'''AAA'''”: '''Arrange''', '''Act''' and '''Assert'''.
Un bon schéma à suivre en ce qui concerne les tests unitaires est "'''AAA'''" : '''Arrange (dans le sens de mettre en place)''', '''Act (dans le sens d’une action faite sur quelque chose)''' et '''Assert (dans le sens de contrôler)'''.
 
Un bon schéma à suivre en ce qui concerne les tests unitaires est “'''AAA'''”: '''Arrange (dans le sens de mettre en place)''', '''Act (dans le sens d’une action faite sur quelque chose)''' et '''Assert (dans le sens de contrôler)'''
 
If you can easily find this pattern in each of your test cases, your tests should be easy to understand, and they should be fairly specific and to the point. One unit test case should test only one thing. Therefore, there should be only one set of AAA in one test case. A test case shouldn’t be very long (longer than 10 lines of code) if it follows the AAA pattern.


Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient facile à comprendre, et ils devraient s’avérer suffisamment spécifiques et aller droit au but. Un cas de test unitaire devrait tester une seule et unique chose. Par conséquent, il devrait y avoir un seul AAA dans un cas de test. Un cas de test ne devrait pas être très prolixe (c’est-à-dire plus de 10 lignes de code) s’il suit le schéma AAA.
Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient être facile à comprendre, et ils devraient s’avérer suffisamment spécifiques et aller droit au but. Un cas de test unitaire devrait tester une seule et unique chose. Par conséquent, il devrait y avoir un seul AAA dans un cas de test. Un cas de test ne devrait pas être très prolixe (c’est-à-dire plus de 10 lignes de code) s’il suit le schéma AAA.


<pre>import unittest class TestGroupForTextWrapping(unittest.TestCase):
<pre>import unittest class TestGroupForTextWrapping(unittest.TestCase):
Ligne 192 : 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 :


* BDD is more “outside-in”, which means that it emphasises more the external behaviour
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 :
* 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 orienté "dehors vers dedans", cela veut dire qu’il met davantage l’accent sur le comportement externe
* 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 [https://pypi.org/project/behave/ behave].
* 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"