Qu'est-ce que les tests unitaires ?
Bonjour à tous, nous avons écrit un petit article sur notre expérience en tests unitaires avec mon coéquipier Berkin Ergürbüz .
Bonne lecture à tous
Les tests unitaires sont une méthode de vérification du comportement de la plus petite unité testable de logiciel en l'exécutant indépendamment de toutes ses dépendances. Les tests unitaires nous permettent de vérifier le comportement du code que nous écrivons en réécrivant du code.Puisqu'il s'agit de la plus petite partie testable du logiciel, les tests unitaires sont développés par les développeurs de logiciels.
QU'EST-CE QUE LE TDD ?
Le Test Driven Development est une pratique que nous entendons fréquemment ces dernières années et qui commence à se généraliser. Fondamentalement, ce qu'il dit, c'est que le test doit être écrit avant d'écrire le code de l'application.
Pourquoi écrivons-nous des tests unitaires et qu'est-ce que cela nous rapporte ?
Pouvoir écrire des tests unitaires présente de nombreux avantages, 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 le développement en écrivant des tests unitaires. Ce processus nous amènera à réfléchir davantage sur la fonctionnalité que nous développerons et nous permettra de nous concentrer uniquement sur les besoins. Commencer directement à coder peut rendre un peu plus difficile pour nous de nous concentrer sur la conception et le flux du code pendant le développement. 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 d'être rédacteur de tests unitaires est de pouvoir remarquer les erreurs qui peuvent survenir lors de la phase de développement et d'avoir la possibilité de corriger ces erreurs. Plus le temps s'écoule entre l'apparition d'une erreur et sa détection, plus le coût de la résolution de l'erreur est élevé.Le test unitaire nous aidera à éviter que ce coût n'augmente.
Notre logiciel est dans une structure en constante évolution et changement, c'est pourquoi nous devrons apporter des modifications à nos méthodes que nous avons écrites. Si les améliorations ou les modifications apportées provoquent une erreur inattendue, cette erreur sera détectée par les tests que nous avons écrits pour ce code auparavant, et nous pouvons réaliser cette situation pendant la phase de développement et prendre les mesures nécessaires. Lorsque nous ajoutons une nouvelle fonctionnalité à une classe dont les tests sont écrits, nous nous concentrons généralement sur les tests de la fonctionnalité ajoutée. Même si cette nouvelle fonctionnalité fonctionne correctement, elle peut empêcher cette classe de remplir une fonctionnalité qu'elle peut remplir dans son état actuel. Il ne nous sera pas toujours possible de tester les cas prédéterminés. 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, en fait, la lettre "O" des principes SOLID, c'est-à-dire que notre méthode est ouverte au développement et va à l'encontre du principe d'être fermé pour changer.
L'écriture de tests unitaires encourage la réduction de la complexité du code et l'écriture d'un code de meilleure qualité. Il sera très difficile d'écrire des tests de méthodes complexes et contenant beaucoup de logique.
Afin d'écrire du code testable, cela nous permettra d'écrire notre code dans des méthodes plus petites et avec une seule tâche dans chaque méthode. Au fil du temps, ces approches nous permettront de créer une culture de développement logiciel pour nous.
Pendant que nous testons nos codes, nous devons être complètement isolés des dépendances externes car le sujet qui nous intéresse est le code de l'unité que nous voulons tester. Nous ne sommes pas concernés par le 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 testons nous permet d'abstraire ces unités et de concevoir le code en petits morceaux réutilisables. A titre d'exemple de dépendances externes; méthodes, points de terminaison de source externe, etc.
En écrivant du code testable, nous commençons en fait à appliquer davantage les principes SOLID.
Comment écrit-on un test unitaire ?
Les étapes de l'approche TDD sont les suivantes ;
1. Le test est développé.
2. Le test échoue.
3. Le codage est fait pour que le test soit réussi.
4. Le test est réussi.
5. Le code est refactorisé.
Avant de commencer ces étapes, il est nécessaire de déclarer les classes et les méthodes pour lesquelles nous allons écrire le test. Il faut d'abord écrire le test des méthodes, puis voir que ce test échoue, coder la méthode correspondante et continuer le processus après que le test soit 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. Notre développement pour qu'une méthode de test réussisse peut entraîner l'échec d'autres tests. Dans ce cas, en refactorisant le code, nous terminons le processus une fois les nouveaux tests réussis.
En dehors de l'approche TDD, nous commençons à écrire après avoir écrit la méthode des tests unitaires dans le processus de développement logiciel traditionnel.
En résumé;
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. L'écriture de méthodes de tests unitaires qui servent vraiment son objectif nous apportera de nombreux avantages. Ainsi, en essayant d'écrire du code testable, nous aurons une culture de développement de code de meilleure qualité. Il devrait servir à détecter les erreurs au stade le plus précoce en prédisant comment une amélioration de notre code affecte d'autres comportements et où nous pouvons obtenir des erreurs.
Dans notre prochain article, nous essaierons d'expliquer comment nous développons des méthodes de tests unitaires et des exemples de processus associés. A bientôt
Nos adresses e-mail pour toutes vos suggestions et commentaires ;
Berkin — [email protected] Fatmagul — [email protected]
Version anglaise de l'article :
![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)
