Qu'est-ce que le test unitaire ?
Salut tout le monde, nous avons écrit un petit article sur notre expérience en tests unitaires avec mon coéquipier Fatmagul Polat . Bonne lecture :)
Le test unitaire est une méthode qui vérifie le comportement d'un logiciel en l'exécutant isolément de toutes les dépendances de sa plus petite unité. Les tests unitaires nous permettent de vérifier le comportement du code que nous écrivons en écrivant du code, et comme il s'agit de la plus petite partie testable du logiciel, les tests unitaires sont développés par les développeurs.
Qu'est-ce que le TDD ?
Le Test Driven Development est une pratique dont on a souvent entendu parler ces dernières années et qui commence à se répandre. Ce qu'il dit essentiellement, c'est que son test doit être écrit avant d'écrire le code de l'application.
Pourquoi développons-nous des tests unitaires et des bénéfices ?
Il y a de nombreux avantages à pouvoir écrire des tests unitaires, nous allons essayer d'en parler.
Le développement avec l'approche TDD nécessite un examen approfondi des exigences ou de la conception avant l'écriture de tout code fonctionnel. Nous commençons par écrire des tests unitaires pour le développement. Ce processus nous amènera à réfléchir plus intensément aux fonctionnalités que nous développerons et nous permettra de nous concentrer uniquement sur les exigences. Commencer à coder directement peut rendre un peu plus difficile pour nous de nous concentrer sur la conception et le flux du code tout en développant . Ce processus nous aidera à faire moins d'erreurs et à écrire un code plus simple et plus propre, en nous concentrant uniquement sur les exigences.
L'un des avantages de l'écriture de tests unitaires est que vous pouvez reconnaître les erreurs qui peuvent survenir au stade du développement et avoir la possibilité de les corriger. Plus il s'écoule de temps entre l'apparition d'une erreur et sa détection, plus il en coûtera pour résoudre l'erreur. Unit Test nous aidera à prévenir cette augmentation des coûts.
Notre logiciel évolue et change constamment, nous devrons donc apporter des modifications aux méthodes que nous avons écrites. Si des améliorations ou des modifications provoquent une erreur inattendue, cette erreur sera capturée par les tests que nous avons déjà écrits pour ce code, et nous pouvons le reconnaître et prendre des mesures dans la phase de développement. Lorsque nous ajoutons une nouvelle fonctionnalité à une classe dont les tests sont écrits, nous nous concentrons généralement sur le test de la fonctionnalité ajoutée. Même si cette nouvelle fonctionnalité fonctionne correctement, elle peut empêcher cette classe d'exécuter une fonctionnalité qu'elle peut actuellement exécuter. Nous ne pourrons pas toujours tester des noix de cajou prédéterminées. Dans de tels cas, le fait d'avoir des tests pré-écrits des fonctionnalités existantes protège contre les erreurs indésirables ou négligées.
Chaque fonctionnalité ajoutée fait échouer nos tests unitaires existants, et si nous devons réorganiser ces tests unitaires, cela va en fait à l'encontre de la lettre "O" des principes SOLID, c'est-à-dire que notre méthode n'est pas ouverte au changement.
L'écriture d'un test unitaire vous encourage à réduire la complexité du code et à écrire un code de meilleure qualité. Il sera très difficile d'écrire le test de méthodes complexes et contenant beaucoup de logique.
Cela nous permettra d'écrire notre code dans des méthodes plus petites pour écrire du code testable, avec une seule tâche dans chaque méthode. Au fil du temps, ces approches créeront pour nous une culture du développement de logiciels.
Lorsque nous testons nos codes, nous devons être complètement isolés des dépendances externes, car ce qui nous intéresse, c'est le code de l'unité que nous voulons tester. Nous ne nous intéressons pas au comportement des dépendances externes. La nécessité de tester indépendamment et isolément des morceaux de code dont dépendent les unités que nous écrivons nous permet d'abstraire ces unités et de concevoir le code en petits morceaux réutilisables. Des exemples de dépendances externes sont les méthodes par lesquelles les opérations sont appelées dans la base de données, l'externalisation des points de terminaison, etc.
En écrivant du code testable, nous commençons en fait à appliquer davantage les principes SOLID.
Des tests unitaires bien écrits contiennent de bons exemples de quelles sorties seront prises lorsque la fonction ou le composant que nous examinons reçoit quelles entrées. Cela nous permet de voir comment le code testé fonctionne comme un chemin heureux, avec des exemples de ce que sont les scénarios finaux. Nous pouvons facilement comprendre comment nos méthodes vont réagir en examinant les tests unitaires. Ces tests peuvent être spécifiques au document du projet. En examinant les tests, il peut être très utile de comprendre le fonctionnement des méthodes.
Comment développer un test unitaire ?
Les étapes de l'approche TDD sont les suivantes ;
1. Développement de tests unitaires.
2. Le test échoue.
3. Le test est codé comme réussi.
4. Le test sera réussi.
5. Le code est refactorisé.
Avant de commencer ces étapes, il est nécessaire de faire une déclaration des classes et méthodes dont nous allons écrire le test. Tout d'abord, nous devons écrire le test des méthodes, puis voir que ce test a échoué, encoder la méthode pertinente et continuer le processus une fois le test réussi.
Après avoir terminé ces processus pour nos méthodes existantes, nous exécutons tous nos tests et nous nous attendons à ce que nos méthodes de test fonctionnent avec succès. L'amélioration que nous apportons pour qu'une méthode de test réussisse peut entraîner l'échec d'autres tests. Dans ce cas, nous refactoriserons le code et terminerons le processus une fois les tests réussis à nouveau.
Outre l'approche TDD, nous commençons à écrire des méthodes de tests unitaires dans le processus de développement logiciel traditionnel.
Pour résumer;
En fin de compte, le but des tests unitaires ne devrait pas être simplement de dire que nous avons des tests unitaires dans notre projet. Écrire des méthodes de tests unitaires qui servent vraiment notre objectif nous apportera beaucoup de choses. De cette façon, nous aurons une culture de développement de code de meilleure qualité en essayant d'écrire du code testable. Cela devrait nous aider à reconnaître les erreurs au stade le plus précoce en anticipant comment une amélioration de notre code affecte d'autres comportements et où nous pourrions obtenir des erreurs.
Dans notre prochain article, nous essaierons d'expliquer comment nous développons des méthodes de tests unitaires et d'expliquer les processus associés en les échantillonnant. À bientôt
Nos adresses e-mail pour tout commentaire et suggestion :
Berkin — [email protected] Fatmagül — [email protected]
Lien vers l'article turc :
![Qu'est-ce qu'une liste liée, de toute façon? [Partie 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)
