Nous aimerions attirer votre attention sur une autre nouveauté disponible dans notre précommande: un livre sur les tests unitaires .
L'auteur de la publication d'aujourd'hui parle brièvement et clairement des avantages des tests unitaires et du TDD en utilisant le front-end comme exemple.
Bonne lecture!
Les tests unitaires sont l'une des approches les plus importantes que tout développeur devrait adopter. Cependant, j'ai vu de nombreux projets où il peut être difficile de mettre en pratique les tests unitaires. Il ya un certain nombre de raisons à cela. Par exemple, quelqu'un pourrait dire que vous devez vous concentrer sur le développement de fonctionnalités, et l'écriture de tests unitaires dans ce cas est un lourd fardeau supplémentaire. D'autres remarqueront que tester leur code n'est pas anodin car le code lui-même est complexe. Dans ces deux cas, le point est manqué.
Je me souviens de cette expression: lorsque vous vous demandez si vous avez le temps d'écrire des tests unitaires, demandez-vous si vous aurez du temps supplémentaire pour traiter le même code deux fois, en raison des bogues et des problèmes qui en émergeront.
Rédaction de code testable
Tout d'abord, définissons les erreurs courantes qui rendent le test de votre code plus difficile. En ce qui concerne les tests frontaux, l'un des problèmes les plus difficiles que je connaisse est celui des composants de l'interface utilisateur. Le principal problème que j'ai rencontré dans ce cas est le suivant: il arrive que les composants soient trop «intelligents» et soient accrochés avec des dépendances sur d'autres fragments de code, par exemple, des appels d'API, du chargement de données, de la gestion des événements et de la mise en œuvre de la logique métier. De nombreux développeurs n'aiment pas écrire des tests pour ces composants "lourds".
La solution la plus simple à ce problème consiste à séparer les composants en logique et présentation. Grâce à cette séparation, vous pouvez tester la manière dont les composants de présentation adhèrent à la logique de présentation, effectuer le traitement et le rendu des événements et vous concentrer séparément sur le test de la logique métier dans les composants responsables de la logique.
S'assurer que vos composants sont testables est également un bon moyen de s'assurer qu'ils sont indépendants, réutilisables et faciles à utiliser ensemble. Ceci est absolument essentiel, en particulier lors du partage de composants entre projets à l'aide d'outils et de plates-formes populaires tels que Bit ( Github). En règle générale, Bit affichera et testera chacun de vos composants séparément, puis ne les enverra qu'à une collection partagée, garantissant ainsi qu'ils sont effectivement réutilisables - sinon, quel est l'intérêt de les rendre séparables.
Exemple: exploration des composants React réutilisables partagés sur Bit.dev
Un cercle vicieux: que se passe-t-il si vous n'écrivez pas de tests unitaires
D'après mon expérience avec des équipes qui n'appliquent pas correctement les tests unitaires (c'est-à-dire n'utilisent pas la couverture des tests comme métrique), soit ont commencé les tests unitaires trop tard, soit depuis le tout début, mais n'ont pas appris à le pratiquer. Il peut y avoir plusieurs raisons à cela, mais je vais donner quelques exemples pour vous aider à décider lequel est le plus similaire à votre cas.
Comment nous testons notre code pendant le développement
À mon avis, à moins que vous ne vous en teniez au développement piloté par les tests (TDD), les fonctionnalités peuvent être développées à condition que le frontend soit constamment chargé dans le navigateur. Vous devez vous concentrer sur la visualisation des fonctionnalités et des interactions qui ont lieu dans l'interface utilisateur, car c'est l'essence même du développement côté client.
Ce n'est qu'après cela, lorsque toutes les fonctionnalités fonctionnent déjà, que l'accent est mis sur les tests unitaires.
Voici le principal problème auquel on doit faire face: l'écriture de tests unitaires est un travail supplémentaire effectué une fois le développement de la fonctionnalité terminé. Cette approche donne l'impression que les tests unitaires sont une tâche supplémentaire effectuée en plus du développement de fonctionnalités prêtes à l'emploi.
En raison de cette formulation de la question, les propriétaires de produits et les développeurs classent les tests unitaires comme un coût.
Mais, si vous vous en tenez au TDD, alors tout se développe exactement le contraire. Comme les cas de test sont écrits à l'avance, nous n'avons pas à tout vérifier en visualisant constamment les changements, car nous avons une manière différente de vérifier le code pendant le développement. Dans ce cas, le principal outil de vérification consiste à écrire du code qui passera le cas de test unitaire.
Par conséquent, je crois que la pratique du TDD est l'étape la plus importante avant la pratique des tests unitaires.
Fréquence d'exécution des tests unitaires
Vous vous demandez peut-être comment l'exécution d'un test unitaire affecte la manière dont les tests unitaires sont écrits. Par exemple, disons que vous disposez d'un ensemble complet de tests. Vous le bannissez de temps en temps. Par conséquent, les développeurs sont rarement convaincus de son utilité. De plus, même dans les cas où le test échoue, il est trop tard.
Par conséquent, il est important d'exécuter des tests unitaires au moins à chaque étape de la génération de la demande d'extraction. En adhérant à cette pratique, tirée de DevOps, nous nous assurons que chaque nouveau bloc de code que nous ajoutons passe un ensemble de tests unitaires. Même s'il est nécessaire de modifier un cas spécifique, le développeur le fera avant l'acte de fusion de code.
À quelle fréquence mesurer la couverture de code par des tests
Comme pour l'exécution de tests, cette mesure est également importante à la fois psychologiquement et en tant que pratique pour que les développeurs jugent s'ils préparent suffisamment de cas de test pour couvrir tout le code écrit.
Dans ce cas, je pense que le tableau de bord seul ne suffit pas, dans lequel vous pouvez voir la couverture des tests unitaires. Mais, s'il était possible d'ajouter un acte de mesure lors de l'ajout d'un nouveau code et ainsi de vérifier le niveau de couverture du test, une telle alternative serait plus pratique pour obtenir un retour instantané. Nous pourrions même formuler des règles exigeant que tout nouveau code ajouté à la base de données soit couvert par des tests, disons à 80%. Il est plus approprié d'ajouter cette validation au processus de génération de la demande d'extraction.
Étant donné que les développeurs reçoivent des commentaires instantanés sur la couverture des tests unitaires de leur code, ils sont libres de prendre des mesures pour rattraper cette couverture si nécessaire.
Sortir de ce cercle
Si vous êtes déjà engagé dans ce cercle vicieux, alors le meilleur moyen d'en sortir est de renforcer les pratiques évoquées ci-dessus. Étant donné que ce qui précède concernait des tests fréquents pour valider le code nouvellement ajouté, ainsi que le test de la couverture du nouveau code, vous pouvez développer une procédure qui convient à toute opération d'ajout ou de modification de code.
Il est extrêmement improbable que vous ayez suffisamment de temps pour couvrir tout l'ancien code avec des tests (à moins que le projet lui-même ne soit complètement nouveau) tout de suite, avant d'avoir à écrire un nouveau code. Par conséquent, ne comptez pas du tout là-dessus, car d'un point de vue commercial, ce n'est pas pratique.En attendant, vous pouvez effectuer des mesures périodiques, couvrant stratégiquement certaines parties de l'ancien code avec des tests. Plus important encore, vous devez former tous les développeurs à suivre cette pratique. Il est tout aussi important de ne pas apprendre à considérer ce travail comme un coût et de faire comprendre à tous les maîtres d'ouvrage à quel point il est important d'écrire des tests unitaires. Sinon, beaucoup de gens, en particulier les non-techniciens, peuvent penser que les tests unitaires sont un travail inutile, au lieu duquel on pourrait passer du temps à développer de nouvelles fonctionnalités.
Alors quelle est la vraie valeur de tout ce travail
Les tests unitaires sont utiles à bien des égards. S'ils sont appliqués correctement, ils aident à réduire le nombre de défauts dans le code, agissent comme une assurance lors du test des fonctionnalités existantes, ne sont pas endommagés lors de la refactorisation du code et aident également à maintenir la productivité globale à un niveau élevé.
En regardant le code bien couvert par les tests unitaires, tout le monde peut voir à quel point il a l'air confiant.Alors comblons les lacunes et remettons sur les rails en adoptant les pratiques DevOps et en nous habituant à écrire de bons tests unitaires tout en s'en tenant au développement piloté par les tests.