A quel point les assertions sont-elles trop nombreuses dans les tests d'automatisation ?

Question

On m'a confié la tâche de construire une combinaison de tests à l'aide de testcafe et, au fur et à mesure que j'écris des tests, je bute sur une question particulière : "combien d'assertions sont trop nombreuses ?". En fait, une fois les tests terminés, un rapport est généré. En regardant ce rapport, il n'est pas intuitif. Par exemple, Si un élément n'est pas trouvé sur la page web, je verrai quelque chose comme :

>Selector('tads') does not exist in the DOM. 

Cela m'oblige à reprendre le test manuellement pour vérifier ce qui a échoué.

Selon la documentation de testcafe, vous pouvez ajouter un message facultatif à l'assertion. comme vu ici

Pour l'instant, j'ai des assertions avec des messages à quelques endroits. Serait-il judicieux d'avoir une assertion (avec un message d'erreur concis) après chaque clic ou chaque action ? (par exemple, cliquer sur le bouton de connexion, faire une assertion pour voir si la modale de connexion apparaît. Maintenant, connectez-vous, vérifiez que la modale de connexion disparaît).

Le code ressemblerait à quelque chose comme ceci :

await t.click(this.loginButton);
await t.expect(this.loginButton.exists).ok("I don’t see the login button");

await signup.newUserSignUp();
await t.expect(this.loginButton.exists).notOk("The login modal didn’t disappear"); 

Tout commentaire serait le bienvenu.

Answer 1

Les assertions TestCafe peuvent être utilisées pour affirmer ce qui est attendu dans un test, mais aussi comme mécanisme d'attente pour s'assurer qu'un élément est prêt avant d'agir sur lui.

Cela signifie que vous pouvez vous retrouver avec de nombreuses assertions dans un seul test.

Personnellement, j'écris chaque test dans un style BDD comme ceci :

fixture("Feature <feature-id>: description of the feature ");

test("Scenario <scenario-id>: description of the scenario", async (t) => {
  // Given 
  await t
   .<any action>
   .<any action>
   ...

  // When
  await t
   .<any action>

  // Then
  await t
   .expect ... 
   .expect ...
   ...

});

Dans le Given et le When vous pouvez utiliser un t.expect() mais uniquement comme mécanisme d'attente.

Je n'ai jamais non plus mis un message dans le .ok() o .notOk() car lorsqu'un test échoue, je dois toujours le relire manuellement pour vérifier ce qui a échoué.

Ainsi, structurer vos tests dans un style BDD vous aidera à éviter cette question : how much assertions is too much? à cette question : how much tests is too much?