Le TDD, vous aimez, vous avez essayé … Mais ..!

  1. Mise en contexte

Les approches TDD (Test Driven Developpement) et ATDD (Acceptente  Test Driven Developpement) sont des outils que toutes organisations qui veulent se tourner les méthodologies Agiles devraient utiliser.

C’est une approche qui est bien documentée et il existe beaucoup de formations qu’on peut suivre qui va vous expliquer l’art et la science sur le comment faire des tests automatisés de vos développements logiciels.

Aux files des années, j’ai vu plusieurs organisations ont voulu se lancer en lisant cette bonne documentation et envoyant leurs ressources faire les formations. Elles ont aussi beaucoup de temps à mettre en place les outils tel que NUnit ou Ms-Tests, JUnit .. ou autre framework de tests.. Mais, le “Mais du titre” malgré les efforts, le temps et même l’argent. Vous n’en avez pas fait le succès tant recherché.

Conséquence, vous avez arrêté d’en faire. Car, vous n’y voyez plus votre profit à l’exercice.

  1. La transformation, elle n’est pas facile à faire

Mais, la vie et aussi en informatique. Il faut parfois faire une bonne préparation. Même si l’approche est bien documentée, je le reconfirme. Il faut mettre en place des choses, voir faire des ajustements dans vos environnements avant d’ajouter cette suite d’outils dans votre arsenal.

Imaginer que vous toujours utiliser le langage Cobol dans un environnement central. Mais, du jour au lendemain, vous décider de passer à un environnement Web genre ASP.NET en C#. Il ne suffira pas de former, au langage C#, vos ressources. Ils devront apprendre une toute nouvelle manière de programmer. Mais, vos architectes devront aussi penser différemment leurs désignes d’applications. 

C’est la même chose, lorsqu’on veut de se lancer dans les approches de type TDD. Il y a des devoirs à faire. Il faut aussi apprendre à nos programmeurs à faire des tests. Toutes les formes de tests et pas seulement ceux automatisés. Car, avant de faire des tests automatisés, il faut savoir bien tester et surtout savoir qu’est-ce que c’est un test.

Ils devront aussi apprendre à programmeur leurs classes, leurs fonctions. Autrement dit, revenir à la base des techniques de programmation. Car, un vrai test, ça doit tester une seule chose. Et dans nos livres d’initiation à l’université, une fonction devait aussi faire une seule chose.

C’est la même chose au niveau du design Les classes doivent avoir cette d’être dite testable. J’attends par testable, qu’elle soit simple à construire le code qui fera le test de la fonction et des fonctions.. Le temps normal d’un test unitaire automatisé devrait être quelque secondes (2-5 secondes. Voir généralement, moins d’une seconde.

Donc, il faut aussi penser un design pour facile à tester. J’ai déjà vu des classes que pouvoir faire un des  tests automatisés avec elle. Il fallait mettre plusieurs heures de travail, pour automatiser la création du test et je ne parle du grand nombre des lignes de code qu’on doit écrire. On vient presque être obligé de faire un test fonctionnel pour ce qui devait être à l’origine un test unitaire.

  1. On fait comment ?

Bravo, vous avez décidé de poursuivre ! Mais, vous voulez savoir comment on fait ?

La première étape, je crois que vous l’avez fait, c’est-à-dire donner une formation sur l’art du test automatisé. Ils sont heureux , (je vous le souhait et je l’espère) d’avoir fait cette formation. Mais, malgré qu’ils aient un bel outil entre les mains.

Il faut passer à la prochaine étape, mettre le cadre d’utilisation de ce nouvel outil. Ce n’est pas parce que vous avez choisi d’utiliser cette approche qu’il faut l’utiliser partout d’un premier temps.  Je recommande d’abord le faire sur un petit projet. Comme dit si bien, l’expression, l’expérience s’acquièrent avec le temps.

Voir peut-être, permettre d’abord seulement à certaines ressources de l’utiliser dans un petit projet ou partie d’un projet. Trop souvent, les organisations veulent faire ce virage en grande vitesse, et ce, n’est pas toujours une bonne idée.

Profitez-en pour définir sur quoi , ils seront utilisés. Car, les tests automatisés ne convient pas à tout et pour tout. Vous n’aurez peut-être pas tous les gains d’une intégration complète. Mais, la partie où ils seront utilisés vous apportera d’un premier temps la rentabilité tant recherchée.

  1. Plus qu’un framework générique

L’autre chose importante qu’il faut réfléchir. C’est que parfois nous avons besoin plus les outils d’un framework générique. Un framework générique comme son nom l’indiquent,  sont conçus pour faire un travail générique.

Donc, parfois, lorsqu’on veut lui faire un travail plus particulier ça demande une connaissance particulière. Mais, pourquoi faire évoluer cette solution générique vers une solution plus particulière qui répondra à vos besoins.

Exemple, vous testez souvent des dates de transactions qui doivent être validé dans des conditions que vous pouvez généraliser. Pourquoi ne pas vous en faire un kit de tests prédéfinis.

En établissant cette suite de tests, vous pourrez facile vous assurez de leurs qualités. Mais aussi, facilité le travail de vos programmeurs.

  1. En conclusion

Choisir de faire un passage aux tests unitaires automatisés n’est pas une chose simple. Elle doit se faire en plusieurs étapes tout comme toutes les transitions vers une méthodologie Agile.

Elle aura des impacts partout dans votre développement logiciel. Mais, si vous persister que vous faites les bons choix et que vous avez un bon accompagnement. Je crois qu’avec le temps, vous en ferez un succès.

  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

%d blogueurs aiment cette page :