Pourquoi le développement piloté par les tests (TDD) est le meilleur moyen de coder de manière robuste.

Commencez par écrire les tests unitaires, puis écrivez le code.

Crédits d'image: Pexels.com

Il y a quelques années, lorsque j'ai entendu parler de «Test Driven Development», j'étais sceptique.

L'idée même de “d'abord écrire des tests unitaires, puis écrire le code” était pour moi charabia.

Pourquoi ne le serait-il pas? Écrivez vos tests unitaires en premier? Qui ferait une chose idiote comme ça?

Mais j’étais un programmeur professionnel depuis 10 ans et j’avais vu les choses aller et venir dans l’industrie. Je savais qu'il valait mieux que d'écarter quoi que ce soit, surtout lorsque les développeurs étaient si enthousiastes.

J'ai donc consulté un ami à moi qui m'a montré un exemple de base.

Cet exemple de base a une classe LCL_SUM avec une méthode SUM. La responsabilité de cette méthode est d’ajouter les chiffres. Il prend un nombre en tant que paramètre d'importation, puis l'ajoute à lui-même pour obtenir le résultat. Appelons cette méthode une méthode de production.

Le code de la classe était comme ceci:

CLASS lcl_sum DEFINITION.
SECTION PUBLIQUE.
MÉTHODES: SOMME IMPORTATION iv_1 TYPE i
VALEUR DE RETOUR (rv_sum) TYPE i.
ENDCLASS. “Lcl_sum DEFINITION
*
DEBUT DE SELECTION.
* Rien ici pour l'instant
*
*
CLASS lcl_sum IMPLEMENTATION.
METHOD SUM.
rv_sum = iv_1 * iv_1. “Erreur délibérée (je multiplie au lieu d'ajouter)
ENDMETHOD. "somme
ENDCLASS. “Lcl_sum MISE EN ŒUVRE.

Configuration de la classe de test

Créez maintenant une classe qui agit comme une classe de test. Dans SAP, vous devez ajouter le mot clé FOR TESTING lors de la définition de la classe. Cet ajout sépare cette classe du code de production.

CLASS lcl_test DÉFINITION DE TESTER
SECTION PUBLIQUE.
Méthodes: m_sum pour les tests.
ENDCLASS. “Lcl_test DEFINITION
*
CLASS lcl_test MISE EN ŒUVRE.
METHODE m_sum.
ENDMETHOD. «M_sum
ENDCLASS. “Lcl_test MISE EN ŒUVRE

Mise en oeuvre de méthodes de test

Dans cette méthode de test, vous devez: tester le code de production. Ainsi, pour pouvoir tester la méthode SUM de LCL_SUM, vous devez instancier une référence d'objet à LCL_SUM, appelez la méthode SUM qui envoie la valeur factice.

Sur la base de la valeur factice, la méthode vous enverra le résultat - le résultat réel de la méthode. En fonction de la valeur factice, vous savez quelle serait la valeur attendue. Par exemple. Si vous passez le nombre 3 à la méthode SOMME, vous obtiendrez le résultat 6 car il s’ajoute à 3.

Une fois que vous avez reçu le résultat réel du code de production ou de la méthode testée, vous devez comparer les résultats. Si la valeur réelle et attendue ne correspond pas, vous devez informer le système que quelque chose ne va pas avec la valeur réelle et attendue et afficher un message approprié.

CLASS lcl_test MISE EN ŒUVRE.
METHODE m_sum.
DATA: o_cut TYPE REF TO lcl_sum.
DATA: lv_result TYPE i.
*
CREATE OBJECT o_cut.
lv_result = o_cut-> sum (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = "quelque chose de mal en sortie"
)
ENDMETHOD. «M_sum
ENDCLASS. “Lcl_test MISE EN ŒUVRE

Résultats des tests unitaires

Cela me dit que quelque chose ne va pas dans la mise en œuvre de la méthode de production.

Oui, si vous regardez de près l’implémentation de la méthode SUM, j’ai une faute de frappe - au lieu d’utiliser Summation, j’avais utilisé Multiplication. Donc, je le corrigerais et relancerais le test pour l'exécuter avec succès.

J'étais accro à TDD. Étourdi serait le mot juste.

Ce qui était étonnant, c’était le temps de cycle de développement et de test très réduit.

J'avais l'habitude d'écrire du code pendant près d'une heure avant d'essayer de le compiler ou de l'exécuter. Mais ici, le code était exécuté et testé toutes les 2 minutes environ.

Ainsi, en résumé, la TDD est réalisée au travers de cycles de développement courts qui suivent la règle «écrivez d’abord des tests unitaires, puis écrivez le code, puis refactorez, puis répétez». Les tests unitaires sont des tests automatisés qui vérifient si les fonctions fonctionnent comme prévu. Votre tout premier test unitaire devrait échouer car il est écrit avant même d’avoir une base de code.

Vous ajoutez un peu au code du cas de test. Vous ajoutez un peu au code de production. Les deux flux de code deviennent simultanément des composants complémentaires. Les tests correspondent au code de production comme un anticorps correspond à un antigène.

Cette mesure empêche les développeurs d’écrire du code inutile qui n’est pas conforme au test donné.

Et toute cette approche intégrée offre de nombreux avantages au développeur.

Vous corrigez le mauvais code sans rien casser.

Chaque fois que vous voyez un mauvais code, vous levez les yeux au ciel, priez Dieu et prononcez l'une des deux déclarations.

· "Ceci est un gâchis. Je suppose que je dois en quelque sorte le réparer ».

· "Je ne le touche pas."

Dans les deux cas, il y a un élément de peur impliqué. En fait, incertitude.

Et si mon code casse la fonctionnalité existante?

TDD vous aide précisément à surmonter cette incertitude.

Il est important de noter que dans un environnement TDD, les développeurs se concentrent sur l'exécution de tests pour éviter les bogues plutôt que pour les supprimer après l'écriture du code. C'est l'un des avantages les plus puissants du TDD. Lorsque vous faites confiance à une série de tests, vous ne craignez plus de faire des changements. Lorsque vous voyez un mauvais code, il vous suffit de le nettoyer sur place.

Et plus votre code est ordonné, moins votre équipe devra s’efforcer d’ajouter de nouvelles fonctionnalités ou de modifier le code existant.

TDD applique la documentation.

Dick Brandon a frappé le clou quand il a observé.

«La documentation, c'est comme le sexe. quand c’est bon, c’est très très bon, et quand c’est mauvais, c’est mieux que rien. ”

La documentation est l'huile de ricin de la programmation. Les gestionnaires pensent que c'est bon pour les programmeurs et que les programmeurs détestent ça!

L’absence de documentation avec des exigences clairement définies est l’une des raisons courantes du glissement de la portée. Ce problème peut être atténué par un développement piloté par des tests.

Dans un environnement TDD, les développeurs écrivent des tests unitaires pour tester des segments de code particuliers. Les tests unitaires servent de spécifications décrivant les fonctionnalités précises à implémenter. Par conséquent, des tests bien spécifiés empêchent les développeurs d’écrire du code superflu.

Et ces tests unitaires sont des documents. Ils décrivent la conception de niveau le plus bas du système. Ils sont sans ambiguïté, exacts, écrits dans une langue que le public comprend et sont si formels qu’ils s’exécutent. Ils constituent le meilleur type de documentation de bas niveau pouvant exister.

TDD contribue à une meilleure conception

La condition préalable fondamentale de TDD est que vous devez écrire vos cas de test unitaires avant d'écrire le code.

Le problème avec le code de test est que vous devez isoler ce code. Il est souvent difficile de tester une fonction si celle-ci appelle d'autres fonctions. Pour écrire ce test, vous devez trouver un moyen de découpler la fonction de tous les autres. En d'autres termes, la nécessité de tester d'abord vous oblige à penser à une bonne conception.

Cela crée une meilleure conception découplée dans laquelle vous avez un meilleur contrôle sur le développement du code.

La rédaction initiale de cas de test peut prendre beaucoup de temps au départ, mais cela apporte de nombreux avantages. Les développeurs admettent qu'ils utilisaient auparavant pour écrire des lignes de code, se rendent compte que leurs solutions n'étaient pas pertinentes, puis recommencent à coder à nouveau.

Contrairement aux pratiques de codage obsolètes, TDD permet aux développeurs de revenir à la phase de conception et de se concentrer sur la conception d'une architecture légère et flexible.

Et le simple fait d'écrire des scénarios de test dès le départ empêche tout bogue susceptible de se produire plus tard, ce qui vous fait économiser du temps, des efforts et des brûlures d'estomac.

Et enfin, TDD suit les meilleures pratiques de codage.

TDD promeut de bons principes de codage, notamment DRY, KISS, YAGNI et SOLID.

Le principe DRY (Ne vous répétez pas) demande aux développeurs d’éviter de répéter le même code dans différentes parties du même système. C’est pourquoi il est parfois appelé le principe DIE (Duplication Is Evil). DRY recommande aux développeurs d'utiliser des classes et des fonctions pour encapsuler les fonctionnalités du système et maintenir une base de code cohérente.

Le principe KISS (Keep it Simple, Stupid!) Recommande aux développeurs de ne pas réinventer la roue, mais de construire des architectures simples et claires. L’essence de KISS est d’éviter les solutions trop techniques.

Le principe YAGNI (vous n’allez pas en avoir besoin) combat le placage d’or. Le placage or peut sembler inoffensif, en particulier si un développeur souhaite améliorer les fonctionnalités existantes pour satisfaire un client. Cependant, cela entraîne un temps de développement supplémentaire qui peut entraîner un retard du projet ou un client mécontent. YAGNI le dit clairement: un développeur doit implémenter uniquement les tâches assignées et éviter d'ajouter des fonctionnalités excessives.

SOLID consiste en cinq principes en un: responsabilité unique, Open-closed, substitution de Liskov, ségrégation d’interface et inversion de dépendance. Pour être bref, SOLID indique que le respect de ces principes facilite la maintenance et le test des applications.

En résumé, TDD aide à créer un code simple, élégant et facile à gérer.

Comme Robert Martin l’a bien dit.

"Le code propre a toujours l'air d'avoir été écrit par quelqu'un qui s'en soucie."

Références

Programmation extrême: Kent Beck.

Développement logiciel agile: Robert Martin

Refactoring: Martin Fowler

A propos de l'auteur-:

Ravi Rajan est responsable de programme informatique mondial basé à Mumbai, en Inde. Il est également un blogueur passionné, un écrivain de poésie haïku, un passionné d'archéologie et un maniaque de l'histoire. Connectez-vous avec Ravi sur LinkedIn, Medium et Twitter.

Cette histoire est publiée dans The Startup, la plus grande publication d’entrepreneurship de Medium, suivie de +438 678 personnes.

Abonnez-vous pour recevoir nos meilleures histoires ici.