Qu'est-ce que le test unitaire et pourquoi est-ce important?

Les tests unitaires sont le processus d'écriture et d'exécution automatique de tests pour garantir que les fonctions que vous codez fonctionnent comme prévu. Bien que cela puisse sembler plus de travail, il s'agit vraiment 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 permettent de s'assurer que le composant principal de votre application se comporte comme prévu et qu'un engagement futur 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 ancien code (ou dans un test mal écrit / obsolète).

Le but des tests unitaires est évident: 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 avec 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 des composants plus volumineux qui utilisent plusieurs autres fonctions, qui peuvent eux-mêmes faire l'objet de tests unitaires. Cela vous aide à localiser plus efficacement les erreurs. L'erreur se situe-t-elle dans les méthodes de l'objet grand composant ou dans l'un des autres composants qu'il utilise?

Si les tests unitaires sont 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 manuel manuel détectera de nombreux bogues de logique 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 des dinosaures – 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 par crainte. pourrait tout casser.

D'une certaine manière, lorsque vous écrivez des tests unitaires, vous écrivez de la documentation pour cela. Vous n’avez peut-être pas besoin d’écrire un manuel complet, mais vous définirez toujours deux choses: ce que vous devez donner à la fonction et ce qu’elle renvoie, de la même manière que vous définiriez un schéma d’API. Grâce à ces deux informations, vous savez clairement 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 serez en mesure d’écrire vos tests avant la fonction 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 serez peut-être également 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 en fin de compte dépendra du langage 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:

• Organisez, 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 des éléments, vous devez commencer par le faire.
• Act, où l'unité est appelée et la réponse est enregistrée.
• Affirmez, là où se déroule l'essentiel des tests. C'est là 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 la pile de ce qui s'est mal passé, de ce à quoi vous vous attendiez et de ce qui a été réellement renvoyé.

Jest a un tas de différents matchers, qui vous permettent d'effectuer des assertions rapides et simples. Par exemple, disons que vous avez 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, il est enregistré avec la fonction sous functionName.test.js. Jest recherchera automatiquement ces fichiers lors de l'exécution des tests.

le .toBe() function 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 obtenir la liste complète de leurs correspondants pris en charge.