Placement correct des stubs dans la classe de test Junit pour wiremock

Question

J'ai trouvé le code ci-dessous dans aquí . Tous les stubs sont créés dans @Before section.

@Rule
public WireMockRule wireMockRule = new WireMockRule(18089);

private HttpFetcher instance;

@Before
public void init() {
    instance = new HttpFetcher();

    // all the stubs
    stubFor(get(urlEqualTo("/hoge.txt")).willReturn(
            aResponse().withStatus(200).withHeader("Content-Type", "text/plain").withBody("hoge")));
    stubFor(get(urlEqualTo("/500.txt")).willReturn(
            aResponse().withStatus(500).withHeader("Content-Type", "text/plain").withBody("hoge")));
    stubFor(get(urlEqualTo("/503.txt")).willReturn(
            aResponse().withStatus(503).withHeader("Content-Type", "text/plain").withBody("hoge")));
}

@Test
public void ok() throws Exception {
    String actual = instance.fetchAsString("http://localhost:18089/hoge.txt");
    String expected = "hoge";
    assertThat(actual, is(expected));
}

@Test(expected = HttpResponseException.class)
public void notFound() throws Exception {
    instance.fetchAsString("http://localhost:18089/NOT_FOUND");
}

@Test(expected = HttpResponseException.class)
public void internalServerError() throws Exception {
    instance.fetchAsString("http://localhost:18089/500.txt");
}

@Test(expected = HttpResponseException.class)
public void serviceUnavailable() throws Exception {
    instance.fetchAsString("http://localhost:18089/503.txt");
}
}

Est-ce la bonne approche ? Ne serait-il pas plus judicieux de créer le stub en @Test elle-même (afin que les stubs liés à ce test puissent être identifiés facilement).

Answer 1

L'approche "correcte" est toujours discutable.

Le code de la méthode @Before sera exécuté à chaque fois, avant chaque méthode @Test.

En gardant cela à l'esprit, vous pouvez choisir de les laisser là ou de les déplacer vers chaque méthode de test.

Pour ma part, j'accorde une grande importance à la lisibilité, et je suis d'accord pour dire que puisque ces stubs ne sont pas du tout partagés entre les tests, mettre chaque stub dans le test qui l'utilise serait plus lisible (et donc meilleur).

Answer 2

Lorsque vous écrivez des tests unitaires, vous devez toujours trouver un équilibre entre les meilleures pratiques "génériques" (telles que : "éviter à tout prix la duplication du code") et les meilleures pratiques "spécifiques aux tests unitaires" (telles que : idéalement, toutes les connaissances nécessaires à la compréhension d'une méthode de test sont situées sur cette méthode d'essai).

Dans ce sens, une approche raisonnable pourrait être :

• Les paramètres partagés par plusieurs scénarios de test pourraient être placés dans une méthode @Before setup().
• les paramètres utilisés par un seul scénario de test ... ne sont utilisés que dans ce scénario de test.