LeSS - Tests unitaires - Historique des versions

Nicolas Mereaux : Ajout encadré

2022-07-03T19:01:37Z

Ajout encadré

← Version précédente		Version du 3 juillet 2022 à 19:01
Ligne 134 :		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

Nicolas Mereaux : Ajout relecteur

2022-07-03T18:05:09Z

Ajout relecteur

← Version précédente		Version du 3 juillet 2022 à 18:05
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 />
	----		----

Fabrice Aimetti : /* La règle d’or du test unitaire */

2022-06-30T11:01:35Z

La règle d’or du test unitaire

← Version précédente		Version du 30 juin 2022 à 11:01
Ligne 148 :		Ligne 148 :
	'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''		'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''

	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.

Fabrice Aimetti : /* La règle d’or du test unitaire */

2022-06-30T11:00:25Z

La règle d’or du test unitaire

← Version précédente		Version du 30 juin 2022 à 11:00
Ligne 143 :		Ligne 143 :

	=== 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 :

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

2022-06-30T10:59:53Z

Développement piloté par le comportement (BDD)

← Version précédente		Version du 30 juin 2022 à 10:59
Ligne 140 :		Ligne 140 :
	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 :		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		* Le BDD est davantage orienté "dehors vers 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].		* 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].

	=== La règle d’or du test unitaire ===		=== La règle d’or du test unitaire ===

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

2022-06-30T10:57:37Z

Développement piloté par le comportement (BDD)

← Version précédente		Version du 30 juin 2022 à 10:57
Ligne 139 :		Ligne 139 :

	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 :		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
	* 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].		* 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].

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

2022-06-30T10:55:35Z

Développement piloté par le comportement (BDD)

← Version précédente		Version du 30 juin 2022 à 10:55
Ligne 131 :		Ligne 131 :
	=== 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~~

	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
Ligne 144 :		Ligne 137 :
	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 :

	* BDD is more “outside-in”, which means that it emphasises more the external behaviour		* BDD is more “outside-in”, which means that it emphasises more the external behaviour

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

2022-06-30T10:54:04Z

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

← Version précédente		Version du 30 juin 2022 à 10:54
Ligne 113 :		Ligne 113 :
	=== Arranger, Agir, Auditer (''Arrange'', ''Act'', ''Assert'') ===		=== Arranger, Agir, Auditer (''Arrange'', ''Act'', ''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 ê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.

	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.

	<pre>import unittest class TestGroupForTextWrapping(unittest.TestCase):		<pre>import unittest class TestGroupForTextWrapping(unittest.TestCase):

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

2022-06-30T10:52:25Z

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

← Version précédente		Version du 30 juin 2022 à 10:52
Ligne 113 :		Ligne 113 :
	=== 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.		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.

Fabrice Aimetti : /* Pas de nouvelles, bonnes nouvelles */

2022-06-30T10:25:54Z

Pas de nouvelles, bonnes nouvelles

← Version précédente		Version du 30 juin 2022 à 10:25
Ligne 105 :		Ligne 105 :
	Règle empirique :		Règle empirique :

	~~<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.		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>~~
			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é.

	[[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é à débogguer le code concerné.

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

LeSS - Tests unitaires - Historique des versions

Nicolas Mereaux : Ajout encadré

Nicolas Mereaux : Ajout relecteur

Fabrice Aimetti : /* La règle d’or du test unitaire */

Fabrice Aimetti : /* La règle d’or du test unitaire */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

Fabrice Aimetti : /* Pas de nouvelles, bonnes nouvelles */

Nicolas Mereaux : Ajout encadré

Nicolas Mereaux : Ajout relecteur

Fabrice Aimetti : /* La règle d’or du test unitaire */

Fabrice Aimetti : /* La règle d’or du test unitaire */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Développement piloté par le comportement (BDD) */

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

Fabrice Aimetti : /* Arranger, Agir, Auditer (Arrange, Act, Assert) */

Fabrice Aimetti : /* Pas de nouvelles, bonnes nouvelles */