Index général
- Outils
- Références
- Tuyaux
This is an old revision of the document!
Voir pour plus de détail le livre p. 96 de ISBN 978-3-030-24094-3, Introduction to Software Design with Par Robillard, Martin P. Il devrait être disponible à la bibliothèque et vous trouverez une version électronique en ligne. (voir plus bas dans la catégorie référence).
Beaucoup des éléments qui suivent en sont une simple traduction.
Une question courante lors de la construction d'une suite de tests unitaires est de savoir comment organiser nos tests de manière sensée. Il existe différentes approches, mais en Java un idiome commun est d'avoir une classe de test par classe de projet, où la classe de test rassemble tous les tests qui testent les méthodes ou autres scénarios d'utilisation qui impliquent la classe.
De plus, il est de pratique courante de localiser tout le code de test dans un dossier source différent avec une structure de paquet qui reflète la structure du paquet du code de production. La raison d'être de cette organisation est que dans Java les classes avec le même nom de paquet sont dans la même portée de paquet indépendamment de leur emplacement dans un système de fichiers. Cela signifie que les classes et les méthodes du paquet de test peuvent se référer à des classes non publiques (mais non-privés) des membres des classes du code de production, tout en étant toujours séparés du code de production.
Écrire des tests unitaires pour des classes non triviales est souvent un processus créatif difficile, un peu comme écrire un code de production. Pour cette raison, il n'existe pas de formule ou de modèle standard pour écrire le code d'un test unitaire. En fait, parcourir les suites de tests de différents projets open-source montrera que les différentes communautés suivent des styles différents et utilisent des techniques de test différentes. Ceci étant dit, certains principes de base sont généralement acceptés, notamment que les tests unitaires doivent être rapides, indépendants, répétitifs, ciblés et lisibles[1].
En utilisant l'annotation @BeforeEach, nous indiquons à JUnit d'exécuter la méthode avant l'exécution de tout test. De même, il est également possible d'utiliser la notation @After Après une notation annotation pour marquer une méthode qui doit être exécutée après chaque test (par exemple pour libérer certaines ressources). Bien sûr, les objets immuables n'ont pas besoin d'être réinitialisés, ils peuvent donc être stockés comme champs statiques de la classe.
Une fixture est un morceau de code qui permet de fixer un environnement logiciel pour exécuter des tests logiciels. Cet environnement constant est toujours le même à chaque exécution des tests. Il permet de répéter les tests indéfiniment et d'avoir toujours les mêmes résultats. (Wikipedia)
package testRobillardBook; import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; public class TestFoundationPile { // Test Fisture private static final Card ACE_CLUBS = Card.get(Rank.ACE, Suit.CLUBS); private static final Card TWO_CLUBS = Card.get(Rank.TWO, Suit.CLUBS); private static final Card THREE_CLUBS = Card.get(Rank.THREE, Suit.CLUBS); private FoundationPile aPile; @BeforeEach public void setUp() { aPile = new FoundationPile(); } @Test public void testCanMoveTo_Empty() { assertTrue(aPile.canMoveTo(ACE_CLUBS)); assertFalse(aPile.canMoveTo(THREE_CLUBS)); } @Test public void testCanMoveTo_NotEmptyAndSameSuit() { aPile.push(ACE_CLUBS); assertTrue(aPile.canMoveTo(TWO_CLUBS)); assertFalse(aPile.canMoveTo(THREE_CLUBS)); } } }
Il n'est pas toujours physiquement possible de tester de façon exhaustive l'espace d'entrée d'un projet. Par exemple, pour tester toutes les comparaisons de deux cartes d'un jeu de 54 cartes, il faudrait faire 1431 tests (ce qui reste faisable), mais pour tester les positions sur un jeu de dames, il y a 443 748 401 247 positions. Même avec un CPU de pointe, tester une méthode pour toutes les positions possibles cela prendrait beaucoup trop de temps et ceci est tout à fait incompatible avec l'exigence selon laquelle les tests unitaires doivent être exécutés “rapidement”.
De toute évidence, nous devons choisir les tests à réaliser parmi toutes les possibilités (par exemple, sélectionner les configurations du jeu de dame à tester). Le défi fondamental du problème de sélection des cas de test est de tester efficacement, c'est-à-dire de trouver un ensemble minimal de cas de test qui nous fournisse une quantité maximale de “test” pour notre code. Malheureusement, bien qu'il soit assez évident de savoir ce qu'est un nombre minimal de cas de test, il n'existe pas de définition naturelle ou même convenue de ce qu'est une “quantité de test”. Aujourd'hui il y a deux façons fondamentales d'aborder la sélection des cas de test :
1. Robert C. Martin. Clean Code: A Handbook of Agile Software Craftmanship. Prentice Hall, 2009.
2. Le livre de référence : https://coderprog.com/introduction-software-design-java/
3. Les codes sources associés au livre : https://github.com/prmr/DesignBook