Q-UNIT-1 : Questions sur les tests unitaires et le TDD

Questions

Questions en rafales

Q1: Quelle est votre position sur le débat actuel à savoir si un test devrait avoir 1 ou plusieurs assert()?

Q2: Pourquoi fait-on du refactoring à chaque boucle dans le TDD?

Q3: Quelle est la différence entre les tests unitaires et le TDD?

Q4: Quelles sont les 3 lois du TDD?

Écriture d’un test en TDD

Q5: Voici un algorithme:

Écrivez en TDD les étapes pour construire incrémentalement la méthode qui fera cette vérification. Documentez le code produit dans le test AccesFilmTest et dans la classe testée AccesFilm à chaque cycle dans les phases respectivement rouge, puis verte.

Étape Phase ROUGE (AccesFilmTest) Phase VERTE (AccesFilm)
1 @Test … public void …
2    

Solutions

R1

En général, il est vrai qu’un test ne devrait avoir qu’un seul assert().

La véritable règle consiste plutôt à dire qu’un test ne devrait avoir qu’une seule raison d’échouer. Si un test a plusieurs raisons d’échouer, il sera difficile
a) d’identifier les raisons de l’échec; b) risque d’échouer sur la première assertion et ne pas exécuter les autres (donc difficile d’avoir un portrait global); c) rendra le réusinage difficile; d) rend le test moins efficace comme documentation; e) etc.

De ce fait, un test pourrait avoir plusieurs assertions tant que ces dernières correspondent à un même COMPORTEMENT.

Un exemple commun de ceci est de s’assurer que tous les éléments d’une liste ont été traités pour un contexte donné. Nous pourrions écrire une assertion pour chacun de ces items, et ce, dans le même test!

R2

(plusieurs réponses possibles)

Afin de nous assurer de constamment ajuster le design (toujours en confiance grâce aux tests) et éviter d’avoir à faire de gros réusinages dangereux. Cela permet aussi de laisser le design émerger avec les tests et les nouvelles fonctionnalités.

R3

Un test unitaire est une sorte de tests (type). Chaque type de test a une raison spécifique d’échouer (ce que l’on veut tester). Le test unitaire vise à s’assurer que les unités (classes) sont solides et fonctionnent techniquement correctement. On vise généralement à trouver des problèmes dans les branches du code (technique) pour guider le développement.**

Le TDD est une discipline qui consiste à écrire les tests avant le code de production à l’aide d’un cycle court alternant entre les tests, le code et du réusinage.

R4

  1. Ne pas écrire du code de production, sauf pour faire passer un test.
  2. Écrire seulement une portion minimale du test qui démontre un échec.
  3. Écrire le minimum de code de production pour faire passer un test.

R5

Aucune solution ne sera donnée.