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

De Wiki Agile
← Modification précédenteModification suivante →
VisuelWikicode
Aucun résumé des modifications
Ligne 38 : Ligne 38 :
* Documentation
* Documentation
** Des tests unitaires bien écrits peuvent servir de documentation de la fonctionnalité du code sous test. Le test unitaire contient des informations que vous ne pouvez pas trouver dans le code testé, comme par exemple, l’objectif de la conception du développeur à l’origine du code, et de quelle manière le code est censé se comporter à l’exécution. Le test unitaire, à la différence de la documentation traditionnelle, ne "ment" pas. Parce que si le test unitaire ment, le test viendrait à échouer. Et dans ce cas, cela indique que le test ou le code est erroné.
** Des tests unitaires bien écrits peuvent servir de documentation de la fonctionnalité du code sous test. Le test unitaire contient des informations que vous ne pouvez pas trouver dans le code testé, comme par exemple, l’objectif de la conception du développeur à l’origine du code, et de quelle manière le code est censé se comporter à l’exécution. Le test unitaire, à la différence de la documentation traditionnelle, ne "ment" pas. Parce que si le test unitaire ment, le test viendrait à échouer. Et dans ce cas, cela indique que le test ou le code est erroné.
* Design tool
** Unit test is also an important design tool. Unit test requires testability from the code understand. Easy-to-test usually means easy-to-use. So unit test could be used to make sure the design has consideration from the perspective of use, rather than only from the perspective of implementation. Testable code needs better modularity and fewer dependencies. So that the unit test can easily take a small part of the code under test (a “unit”) without taking care of the overwhelming amount of dependencies. So unit test could be used to make sure the design has “high cohesion, low coupling”.
* Outil de conception
* Outil de conception
** Le test unitaire est aussi un outil de conception. Pour que le test unitaire remplisse son rôle, il est nécessaire d’appréhender la testabilité du code. Facile à tester veut généralement dire facile à utiliser. Cela signifie que le test unitaire peut être utilisé pour que la conception soit faite du point de vue de l’utilisation et non uniquement du point de vue de l’implémentation. Un code testable doit être davantage modulaire et avoir moins de dépendances. Par conséquence, le test unitaire peut donc facilement ne concerner qu’une petite partie du code testé (un « unitaire ») sans avoir à se soucier de la quantité impressionnante de dépendances qu’il pourrait y avoir. Par conséquent, le test unitaire peut être utilisé pour s’assurer que la conception ait comme caractéristique « une forte cohésion, un faible couplage ».
** Le test unitaire est aussi un outil de conception. Le test unitaire exige que le code soit testable dès sa conception. "Facile à tester" veut généralement dire "facile à utiliser". Cela signifie que le test unitaire peut être utilisé pour que la conception soit faite du point de vue de l’utilisation et non uniquement du point de vue de l’implémentation. Un code testable doit être davantage modulaire et avoir moins de dépendances. Ainsi, le test unitaire peut facilement ne concerner qu’une petite partie du code testé (un "unitaire") sans avoir à se soucier de la quantité impressionnante de dépendances qu’il pourrait y avoir. Par conséquent, le test unitaire peut être utilisé pour s’assurer que la conception ait comme caractéristique "une forte cohésion, un faible couplage".


=== Why on “Unit” Level? ===
=== Pourquoi à un niveau "unitaire" ? ===


=== Pourquoi à un niveau « unitaire » ? ===
"Oui, il est important d’utiliser des tests automatisés pour protéger les fonctionnalités existantes. Mais pourquoi cela doit-il être fait au niveau unitaire ?"


“Yes, it’s important to use automated test to protect the existing functionalities. But why does it need to be on the unit level?”
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 ?
 
« Oui, il est important d’utiliser des tests automatisés pour protéger les fonctionnalités existantes. Mais pourquoi cela doit-il être fait au niveau unitaire ? »
 
You might wonder. Why don’t we just use thorough automated functional or system tests to protect the program?
 
Vous pourriez vous interroger. 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.
'''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.
Récupérée de "https://wikiagile.coach/LeSS_-_Tests_unitaires"