Recherche de site Web

Qu'est-ce que les tests unitaires et pourquoi est-ce important ?


Le test unitaire est le processus d'écriture et d'exécution automatique de tests pour s'assurer que les fonctions que vous codez fonctionnent comme prévu. Bien que cela puisse sembler plus de travail, il s'agit en réalité de prendre des mesures préventives pour éliminer les bogues avant qu'ils ne surviennent.

Qu'est-ce qu'un test unitaire ?

Une unité est le plus petit composant logiciel possible dans votre application (c'est-à-dire des fonctions, des classes ou des composants). Les tests unitaires individuels garantissent que le composant principal de votre application se comporte comme prévu et qu'un futur engagement dans une zone de votre code ne casse pas le code dans une autre. Si c'est le cas, vous avez probablement un bogue dans votre nouveau ou votre ancien code (ou dans un test mal écrit/obsolète).

L'objectif des tests unitaires est évident : réduire les bugs, en particulier ceux qui résultent de l'intégration. Un développeur peut penser que tout va bien localement et valider son code, pour découvrir qu'un autre commit a cassé l'application. Les tests unitaires permettent de détecter certains de ces défauts avant qu'ils ne deviennent des problèmes et, lorsqu'ils sont combinés à des pipelines d'intégration continue automatisés, ils peuvent garantir que la construction quotidienne fonctionne toujours correctement.

Les tests unitaires ne se limitent pas à de petits morceaux de code ; Vous pouvez également tester à l'unité des composants plus grands qui utilisent plusieurs autres fonctions, qui peuvent elles-mêmes être testées à l'unité. Cela vous aide à traquer les erreurs plus efficacement. L'erreur se situe-t-elle dans les méthodes de l'objet composant volumineux ou dans l'un des autres composants qu'il utilise ?

Bien que les tests unitaires soient importants, ils ne sont pas non plus les seuls tests que vous devriez effectuer. L'exécution de tests d'interface utilisateur de bout en bout et d'un examen humain manuel détectera de nombreux bogues logiques que les tests unitaires peuvent manquer lorsque chaque unité fonctionne comme prévu.

Les tests unitaires mènent à des bases de code plus propres

L'un des principaux problèmes avec les bases de code héritées est le code de dinosaure - un code si ancien qu'il s'agit essentiellement d'une boîte noire, vous n'avez peut-être aucune idée de son fonctionnement, mais d'une manière ou d'une autre, cela fonctionne et vous ne voulez pas le refactoriser à cause de la peur pourrait tout casser.

D'une certaine manière, lorsque vous écrivez des tests unitaires, vous écrivez une documentation pour eux. Vous n'aurez peut-être pas à écrire un manuel entier, mais vous définirez toujours deux choses : ce qu'il faut donner à la fonction et ce qu'elle renvoie, de la même manière que vous définiriez un schéma d'API. Avec ces deux informations, il est clair ce que fait la fonction et comment l'intégrer dans votre application. De toute évidence, les tests unitaires ne résolvent pas les anciennes bases de code existantes, mais ils vous empêchent d'écrire ce type de code de dinosaure en premier lieu.

Souvent, vous pourrez écrire vos tests avant la fonction réelle que vous testez. Si vous savez ce que votre fonction doit faire, écrire le test vous oblige d'abord à réfléchir au résultat final de votre code et à ce dont il est responsable.

Si vous aimez cet effet des tests unitaires, vous pourriez également être intéressé par TypeScript, un sur-ensemble compilé de JavaScript qui le rend fortement typé. Vous voudrez toujours écrire des tests unitaires, mais savoir quels types une fonction donne et prend pendant que vous codez est une fonctionnalité très utile.

Comment exécuter des tests unitaires

Il existe de nombreux frameworks de tests unitaires différents, et celui que vous utiliserez finalement dépendra du langage que vous testez. Pour montrer comment ils fonctionnent, nous utiliserons Jest, un framework de test JavaScript qui est la valeur par défaut pour les nouvelles applications React.

Un test unitaire se compose généralement de trois étapes :

  • Organiser, où les données sont préparées pour l'unité à tester. Si vous avez besoin de récupérer des données, de créer un objet complexe ou simplement de configurer certaines choses, faites-le en premier.
  • Act, où l'unité est appelée et la réponse est consignée.
  • Assert, où se déroule l'essentiel des tests. C'est ici que vous écrivez les opérations booléennes basées sur le

Si l'une des assertions échoue, l'unité a échoué au test, et vous obtiendrez un journal détaillé et une trace de la pile de ce qui s'est mal passé, de ce que vous attendiez et de ce qui a été réellement renvoyé.

Jest a un tas de matchers différents, qui vous permettent d'effectuer des assertions simples et rapides. Par exemple, imaginons que vous disposiez de la fonction suivante, qui additionne simplement deux nombres :

function doSomeMath(a, b) {
  return a + b;
}

Vous pouvez tester cette fonction avec l'instruction suivante :

test('Expect math to work', () => {
  expect(doSomeMath(1, 1)).toBe(2);
});

Habituellement, cela est enregistré avec la fonction sous functionName.test.js. Jest recherchera automatiquement ces fichiers lors de l'exécution des tests.

La fonction .toBe() est le matcher, dans ce cas vérifiant l'égalité de base. Il y en a beaucoup d'autres, comme .toBeEqual(), qui vérifie l'égalité des objets, et .toContain(), qui vérifie le contenu du tableau. Vous pouvez lire les documents de Jest pour une liste complète de leurs matchers pris en charge.

Articles connexes: