Bienvenue à Communauté d'utilisateurs .NET Identification | Inscription | Aide

Abonnements

Tags

    No tags have been created or used yet.
Test-Driven Developement (TDD)?, je suis d’accord... mais pas comme ça!

Je sors tout juste d'une présentation de Scott Bellware où le sujet devait être Test Driven Development (TDD). L'événement avait soulevé un bon intérêt puisque Scott a une bonne réputation de présentateur et le TDD, quoi que peu utilisé dans notre région, est une pratique qui est de plus en plus regardée. Bref, il y avait une centaine d'inscription!!! Mais disons que le ballon a dégonflé au fur et à mesure que la soirée avançait.

Tout d'abord, Scott commence en disant qu'il préconise une approche sans aucun modèle pour l'architecture. Seul des cas d'essais unitaires et des cartes de « User story » sont nécessaires à représenter l'architecture d'un système… Bon sur le fait que des « User Stories » sont plus utiles qu'un document de 300 pages qui se noient dans le détail, je peux être d'accord. Par contre, il est absolument aberrent de penser que des systèmes d'une certaines envergure puisse être représenté de cette façon uniquement sans aucun modèle de haut niveau pour découper la complexité.

Par la suite, il préconise une approche ou le nom des méthodes de test reflète la règle d'affaires que le test doit vérifier. Par exemple, « Ajouter un item la commande ». Quoi? Il y des blancs dans le nom de la méthode… que cela ne tienne, Scott a une macro très complexe qui transforme le nom en Ajouter_un_item_la_commande! Bon je peux toujours acheter le principe, mais lorsque la prochaine méthode est Un_client_qui_achete_pour_plus_de_100000_dollars_par_an_a_droit_a_un_rabais_de_20_pourcent, ou Une_commande_avec_un_total_superieur_a_5000_dollars_a_droit_a_un_rabais_de_5_pourcent, on tombe un peu dans l'exagération. De plus nous nous en tenons à un domaine d'affaires simple. Imaginez la longueur d'un nom de méthode pour des essais sur le renouvellement d'une police d'assurance ou le calcul de l'impôt personnel!!!! Ça ne tient pas la route.

C'est vraiment dommage, car je crois sincèrement en la valeur des cadres d'essais unitaire ainsi qu'au Test-Driven Developement. Mais ce soir, Scott a lamentablement échoué à le prouver à son auditoire.

Désolé

Publié 10 mai 2007 23:22 par carolroy

Commentaires

# re: Test-Driven Developement (TDD)?, je suis d’accord... mais pas comme ça! @ 11 mai 2007 08:43

Je penses qu'on devrais plutôt dire 100000_dollars_et_plus et non plus_de_100000_dollars.

;-)

(Il fallait être à la rencontre pour comprendre mon commentaire. La p'tit madame, elle elle comprendra)

gaulu1

# re: Test-Driven Developement (TDD)?, je suis d’accord... mais pas comme ça! @ 14 mai 2007 09:29

Le passage de Scott Bellware n'a laissé personne indifférent ! En regardant les commentaires recueillis, certains ont aimé, d'autres un peu moins. Il y en qui ont trouvé cela trop long et d'autre trop court.  On aurait préféré l'entendre en anglais et on a trouvé qu'il avait un bon français...

kmetivier

# re: Test-Driven Developement (TDD)?, je suis d’accord... mais pas comme ça! @ 15 mai 2007 09:31

Je trouve son idée des tests unitaires qui reflète les règles d'affaires géniale.  Au moins, il a trouvé une manière d'automatiser ses "unit tests" et ses "acceptances tests" ce qui est à mon avis génial.

Louis-Philippe Carignan

lpcarignan

Les commentaires anonymes sont désactivés
Propulsé par Community Server (Commercial Edition), par Telligent Systems