Les tests unitaires sont le processus d'écriture et d'exécution automatique des 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 de 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 commit 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).
Le but des tests unitaires est évident de réduire les bogues, en particulier les bogues résultant 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 aident à 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 unitairement des composants plus volumineux qui utilisent plusieurs autres fonctions, qui peuvent elles-mêmes être testées unitairement. Cela vous aide à traquer les erreurs plus efficacement—l'erreur est-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 faire. L'exécution de tests d'interface utilisateur de bout en bout et d'un examen manuel manuel détectera de nombreux bogues logiques que les tests unitaires peuvent manquer lorsque chaque unité fonctionne comme prévu.
Les tests unitaires conduisent à 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—le code si ancien qu'il s'agit essentiellement d'une boîte noire, vous n'avez peut-être aucune idée de comment cela fonctionne, mais d'une manière ou d'une autre, cela fonctionne et vous ne voulez pas le remanier par crainte qu'il ne casse tout.
Publicité
D'une certaine manière, lorsque vous écrivez des tests unitaires, vous écrivez de la documentation pour cela. 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 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 d'abord vous oblige à réfléchir au résultat final de votre code et à ce dont il est responsable.
CONNEXION : < strong>Qu'est-ce que TypeScript et devriez-vous l'utiliser à la place de Vanilla JS ?
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 dépendra de la langue que vous testez. Pour montrer comment ils fonctionnent, nous utiliserons Jest, un framework de test JavaScript par défaut pour les nouvelles applications React.
Un test unitaire se compose généralement de trois étapes :
- Arranger, où les données sont préparées pour l'unité à tester. Si vous avez besoin de récupérer des données, de construire un objet complexe ou simplement de configurer certaines choses, vous le ferez d'abord.
- Agir là où l'unité est appelée et la réponse est enregistrée.< /li>
- Assert, où se déroule la majeure partie des tests. C'est ici que vous écrivez des 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 pile de ce qui s'est mal passé, de ce que vous attendiez et de ce qui a été réellement renvoyé.
Publicité
Jest propose de nombreux matchers différents, qui vous permettent d'effectuer des assertions simples et rapides. Par exemple, supposons que vous ayez la fonction suivante, qui ajoute 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.
CONNEXES : Comment démarrer avec Jest pour les tests unitaires JavaScript
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.