Convention de nommage des TU

Nommer son test unitaire (TU) pour refléter son sens plutôt que la méthode testée.

bad practice

@Test
void testPi() {
	double actual = Math.pi(5);
	assertThat(actual).isEqualTo(3.14159);
}

Dans cet exemple, on voit que le nom de la méthode ne donne pas le contexte et l’utilité du test.

Pour mieux comprendre l’utilité d’un test, on précise dans son nom ce qu’on attend en résultat et on donne son contexte qui provoque ce résultat. Pour une nouvelle fonctionnalité, deux formats de nom sont couramment utilisés dans les bonnes pratiques :

• Should_ExpectedBehavior_When_StateUnderTest
• When_StateUnderTest_Expect_ExpectedBehavior

Best practice

private static final int NB_PRECISION = 5;
private static final double PI = 3.14159;
 
@Test
void when_precisionIs5_should_returnPiWith5Decimals() {
  double actual = Math.pi(NB_PRECISION);
  assertThat(actual).isEqualTo(PI);
}

En lisant le nom du test, on comprend qu’on lui passe un nombre correspondant à la précision qu’on souhaite avoir en retour du nombre pi.

Le nom du TU est une bonne première étape dans la mise en œuvre de la Method TDD. Il permet de définir l’objectif du test. Plus tard, le nom du test suffira pour identifier la source d’une erreur.

On peut même imaginer générer de la documentation à partir des noms des tests.

---

Source :

• https://cleantestcode.wordpress.com/2014/05/03/names-should-be-expressive-when-writing-tests/