Testing your Application: explain why interdependent tests are bad

In https://github.com/strongloop/loopback4-example-getting-started/pull/2, the proposed acceptance tests are relying on the first test to fill the database with data that's used by subsequent tests:

  it('creates a todo', async () => {
    item = (await client
      .post('/todo')
      .send(payload)
      .expect(
        Object.assign({}, payload, {
          id: 1
        })
      )).body;
  });

  //...

  it('successfully deletes todos', async () => {
    await client.del(`/todo/${item.id}`).send();
    await client
      .get(`/todo/${item.id}`)
      .send()
      .expect(404);
  });

(see https://github.com/strongloop/loopback4-example-getting-started/pull/2#discussion_r147389550)

This is an anti-pattern to avoid:

• if the first test fails, all subsequent tests fail too (because data was not filled in), but with an unhelpful error message is confusing.
• it is not possible to run individual tests on their own, e.g. via it.only() or mocha -g "test name".

We should extend Data Handling in Testing your Application to mention this pattern and explain why it's a bad thing to do.

Commencez par la section « Data Handling in Testing your Application » liée dans l’issue, puis lisez les tests d’exemple référencés et la discussion de la pull request pour comprendre le contexte. Mettez à jour la documentation afin d’expliquer pourquoi les tests interdépendants posent problème et comment les tests indépendants permettent une exécution isolée ; le travail est considéré comme terminé lorsque la propagation en cascade des échecs et l’utilisation de it.only()/mocha -g sont toutes deux couvertes.