Une vérité puissante.

Regardez le code suivant, simple et direct :

function sum(a, b) {
  return a   b;
}

Maintenant, écrivons quelques tests pour cela :

test('sum', () => {
  expect(sum(1, 2)).toBe(3);
  expect(sum(2, 3)).toBe(5);
  expect(sum(3, 4)).toBe(7);
  expect(sum(4, 5)).toBe(9);
});

Nous avons une couverture à 100 %, n'est-ce pas ? Eh bien, oui, nous le faisons, en fait, nous pourrions dire que nous avons obtenu une couverture de 400 % car tout le code est entièrement testé 4 fois, mais le faisons-nous ?

La vérité est que nous ne le faisons pas. Nous testons la fonction avec un ensemble limité d'entrées, et nous ne prenons pas en compte les cas extrêmes, ni nous testons la fonction avec des entrées non valides.

Considérez les éléments suivants :

sum(1, '2');
sum(1, null);
sum(1, undefined);

Que se passerait-il dans un tel scénario ? La fonction générerait-elle une erreur ? Est-ce que cela renverrait une valeur ? Cela briserait-il notre application ?

Soyez conscient du piège de la couverture des tests.

La couverture des tests est un outil puissant, mais ce n'est pas la solution ultime. Il s'agit d'une métrique qui peut vous aider à comprendre dans quelle mesure votre code est testé, mais elle ne vous indique pas dans quelle mesure il est testé.

La couverture des tests peut vous aider en termes de quantité, mais elle ne peut pas faire grand-chose en termes de qualité. C'est à vous d'écrire de bons tests, de prendre en compte les cas extrêmes, de tester votre code avec des entrées non valides et de vous assurer que vos tests sont significatifs et précieux.

Conclusion

C'était un article assez court, je l'avoue, mais j'espère qu'il vous a été utile pour vous rappeler l'importance d'écrire de bons tests. N'oubliez pas que la couverture des tests est un outil et non un objectif. A vous d'en tirer le meilleur parti.

Ciao,

Michel.