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.

Inizia dalla sezione „Data Handling in Testing your Application“ collegata nell’issue, poi leggi i test di esempio referenziati e la discussione della pull request per avere il contesto. Aggiorna la documentazione per spiegare perché i test interdipendenti sono problematici e come i test indipendenti supportano l’esecuzione isolata; il lavoro è completato quando sono trattati sia il propagarsi a cascata dei fallimenti sia l’uso di it.only()/mocha -g.