Importance of test automation, excuses and TDD introduction

25. "What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams." "They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer."

26. "Over 3 iterations, average time taken to complete the kata without TDD was 28m 40s. Average time with TDD was 25m 27s." "Without TDD, on average I made 5.7 passes (delivering into acceptance testing). With TDD, on average I made 1.3 passes (in two attempts, they passed first time, in one it took 2 passes.)" Codeman ship: Code Lab experiment

27. TDD Conclusion • Less bugs • Better code/design • 100% Coverage • Confidence • Documentation • Debug time decreased • It's personal!

28. Conclusion • Discipline & Professionalism • Test prove presence of bugs, not absence • Don't forget « money tests » • Prevention is better than cure (Cost of fix)

29. @nicoDeBoose mechantblog.com On recrute !

Notes de l'éditeur

Pour remplacer cette image, sélectionnez-la et supprimez-la. Cliquez ensuite sur l’icône Insérer une image pour la remplacer par une de vos images.
On va commencer par parler un peu de code spageti. Du code comme ca, tous les dev en ont déjà vu. Pour ceux qui ne connaisse pas bien ce terme en gros, voilà à quoi cela ressemblerait pour un technicien. Comme vous pouvez le voir c’est assez fouilli  Voilà ce qui ralenti le plus les développeurs: le code illisible. En plus d’être illisible, c’est souvent celui qui amène le plus de bug et de dommages collatéraux.
Du coup, ce genre de code, c’est pas celui où tu es le plus confiant… Donc tu as peur de le cleaner… Pourquoi? Parce que si tu le casses... Ca devient ton code! Et donc tu préfère juste laisser le code comme ca plutôt que de cleaner… On en revient à faire ces fameux quick’n’dirty. - Le fameux Quick'n'dirty sur lequel on reviendra plus tard qui est resté là... Et qui s'est accumulé au fil des années pour devenir un animal tentaculaire impossible à dompter. Le code pourri, ca nous ralenti... Pourquoi on écrit du code pourri? Pour aller plus vite... You don't go fast by doing crap +
On s’essouffle peu à peu: Au plus le code pourri Debug devient compliqué… les estimations augmentent... La peur de cleaner augmente
Les managers n’aiment pas avoir de grosses estimations donc on le dit qu’on va changer tout ca ! Epis, on se dit qu'on peut cleaner le code et on promet qu'après tout ira mieux... Que les estimations vont baisser etc… Mais cleaner le code est risky.... On a de la doc qui nous permet de savoir comment les choses doivent fonctionner…. On prend des semaines et après on a pas fait tout ce qu'on voulait, on a passé du temps à débugger des trucs qu'on a refac.
On envoit ca à QA, et là... C'est le drame, on a tellement de bug que la solution la plus censée est de revert les refac parce qu'on sait meme pas estimé la charge de travail. Quand on délivre au QA, on s'attend à quoi? Nothing! C'est le but d'une équipe PRO! sinon c'est pas professionel. Des projets de GROS refactoring sans test, ca marche pas. On attend une new feature et ptit a ptit, en ajoutant les nouvelles feature dans le legacy avec des tests... Certaines parties ne seront pas testées après des années, mais on est confiant que le code fonctionne vu qu'il n'a plus bougé depuis des années... On verra quand il faudra le modifier... Si t'as la choix de modifier ou d'écrire un nouveau module. Fais le nouveau en tdd
C’est assez pour se dire : " Plus jamais on ne nous y prendra!"! Et les managers ne veulent plus entendre parler de refac :)
Le code continue de pourrir, la productivité empire de semaines en semaine… Et on ose plus rien faire… Paralyser par la peur! Bref, on peut pas cleaner du code sans enlever la peur…. Il faut donc pouvoir enlever la peur!
We need a parachute! Comment enlever cette peur? En écrivant des tests! TEST = PARACHUTE
- I have no knowledge, no skills - You must have a leader? - You don't? Then hire one! Avec de l'entrainement, on y arrive. En 2 semaines, on peut arriver à du truc pas trop mal. Quand on y reviendra, on refactorera
Je ne test pas parce que j'ai du code legacy... Vous inquiétez pas vous n'etes pas les seuls? C'est pas trop tard, il y a des techniques et des types de tests... D'ailleurs y'a un livre (voir next slide) là dessus
Michael Feathers: Du code legacy c'est du code sans test. Ici y'a plein d'astuces!
- No time! - I'm must develop features ASAP ... And probably fix bugs? Est-ce que vous vous relisez avant d'envoyer un e-mail important? http://blogs.msdn.com/b/peterhal/archive/2006/01/04/509302.aspx https://blogs.msdn.microsoft.com/peterhal/2006/01/04/what-do-programmers-really-do-anyway-aka-part-2-of-the-yardstick-saga/ According to Peter, developers actually spend their days like this (while not reading Code Rant of course :): Writing new code 5% Modifying existing code 25% Understanding Code 70%
It's like coding twice ... Like accounting ? Do you prefer testing twice? :) More seriously... (next slide)
Un programme est qqchose de sensible. Tu bouges un bit à un endroit et ca peut faire crasher un serveur! Peu de métier sont comme ca... Si tu enlève un clou ou une brique de ta maison, elle ne va pas s'effondrer.. Même dans notre corps, on peut enlever une cellule, et ne mourra pas... ------ La comptabilité par contre, si je me goure d'un chiffre au mauvais endroit, je peux mettre une compagnie en faillite et mettre le boss en prison... Comment il faut? Y'a 700 ans, ils ont trouvé l'astuce: rentrez les infos deux fois: crédit, débit... Après plein de calcul, on doit arriver à zero... Biensur que c'est pas parfait. Le tdd c'est pareil, tout est mis en double. They meet in a green bar. Errors made by programmers moins severe et moins chere que par un comptable? Source code moins important que spreadcheets? Nos employés dependent moins de notre code que de la compte? As professsionel, no... Et by the way, ils font pas tout le débit au début et tout le crédrit à la fin... Ils font ca en meme temps. Pourquoi ne pas faire comme les comptables? Comptabilité en partie double : Néanmoins, ce système était déjà d'emploi fréquent dans les banques italiennes depuis la fin du xiiie. De récentes découvertes (papyrus Boulaq 18) situent cette invention bien plus tôt dans le temps, en Égypte antique, il y a environ 3700 an
The mistake you are making is that you are seeing testing as a time investment with no immediate return. It doesn't necessarily work like that. Lorsqu'on code sans test on rajoute des features, mais rien ne dit que le reste fonctionne... Même le truc qu'on a regardé dans le browser y'a 5 minutes...
That's because your code is not nicely coded maybe :) If your tests are hard to write then, the code they test is probably hard to use and does a lot of things... And is not reusable, decoupled. By reusable, ca veut pas dire dans un autre projet forcément.
L'histoire de faire des tests après: C'est CHIANT! "J'ai plus qu'à écrire mes tests" - Cout des tests: 20%... Et +200% au début! Car un dev va dire: j'ai fini, j'ai plus qu'a tester unitairement... C'est là que ca se corse: Le code est pas testable, il faut refac (+100%), et faire les tests qu'on ne maitrise pas encore vraiment (+100%). Une formation (ou un teacher) est donc plus que recommandée pour éviter ce genre de dérive. Si on écrit les tests après, on aura pas confiance aux tests.. Parce que faire les tests après, c'est chiant, parce qu'on sait déjà que le code fonctionne! C'est pas nécessaire, donc on a l'impression que c'est une perte de temps et qu'on le fait "parce qu'on doit le faire"... Et donc on va prendre des raccourcis DANS LES TESTS (et donc ton parachute)... Il va y avoir des trous... Qui saute avec un parachute avec des trous?
- LA PYRAMIDE du test (mike cohn) - UT: UNITAIRE, Court (et donc moins couteux), debug facile et donc + rapide. Le mythe du code coverage: 100% ne veut rien dire. - Func/Intégration: Plusieurs classes ensemble, Long, debug compliqué(mais pourquoi ce bouton n'est pas disabled, un flag db? Une fonction a retourné autre chose? Le user n'a plus les droits?). Maintenance cher - Scenario/UI/E2E: Très long, debug très compliqué (pourquoi mon panier est vide? Est-ce qu'il a été vidé entre deux pages? Avant que je click sur payer? Ou n'a-t-il tout simplement jamais été rempli?). Maintenance très chere. Il faut de tout pour faire un monde. Tous les TU peuvent passer mais on peut avoir des bugs, d'où la nécessité d'avoir des tests fonctionnels et des scénarios. --------------- On legacy
C'est quoi? On écrite le test qui fail avant le code. Dur de se concentrer sur plusieurs choses en meme temps. Donc on fait les trucs one by one - Tout code est tester (code coverage 100%, on en parle meme plus) - Faire une liste de ce qu'il faut tester - Un bug = un test = une correction - Avantage : Savoir donner un feedback: Voilà une liste de ce qui est dev, voilà ce qu'il reste EXACTEMENT. Et pas un approximatif: j'ai fait 75%. On peut arreter un dev et on sait direct où il en est Interrompt un mec qui fait du tdd, il n'y a pas si longtemps que ca il avait d'office un code qui compilait avec des tests qui passent! Peu importe qui et quand. Comment te sentirais tu si tu savais que TOUT fonctionne comme sur des roulettes 2-3 minutes avant? Ca serait plus simple pour débugger non? Combien de temps tu passerais a debugger ces 2 minutes de dev?
Quand tu écris d'abord les tests, tu trust le test. Le tdd permet de garder un code maintenable avec une bonne architecture. Sans test le code pourri... Pour ca il faut avoir confiance à ses tests... En faisant du tdd par exemple :) Parce que chaque ligne sera là parce pour un but. TDD: Pq on n'écrit pas direct le bon code? Mwé.. Les peintres font des croquis, les compositeurs pareil, journaliste,... etc Les tests, c'est la doc: Tu veux savoir comment utiliser une fonction? Il y a un test pour ca qui pourra te le dire! Ils sont parfaitement sync! Bye bye le cout de la documentation WORD/Pdf/confluence Make production code testable! Un autre mot pour testable = découpled! Improve DESIGN! Yeah
“Over a development cycle of 12 months, 35 percent is another four months, which is huge,” Nagappan says. “However, the tradeoff is that you reduce post-release maintenance costs significantly, since code quality is so much better. Again, these are decisions that managers have to make—where should they take the hit? But now, they actually have quantified data for making those decisions.”. http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx ---- + http://www.codemanship.co.uk/parlezuml/blog/?postid=1021 Over 3 iterations, average time taken to complete the kata without TDD was 28m 40s. Average time with TDD was 25m 27s. Without TDD, on average I made 5.7 passes (delivering into acceptance testing). With TDD, on average I made 1.3 passes (in two attempts, they passed first time, in one it took 2 passes.)
+ http://www.codemanship.co.uk/parlezuml/blog/?postid=1021 jason.gorman
- Le dev doit le sentir Comment on fait en sorte que la team suive? You don't! Let other people take care of theirself. Les autres vont commencer à voir que vous allez plus vite, que le code est plus propre et que vous avez moins de bug... Et là, il sera temps d'assouvir leur curiosité :) tdd is a personal practice (discipline = set or fules), le boss doit pas l'interdire... Chacun son job. On demande pas la permission de mettre des best practices, espace au lieu de tab...
discipline & profesionalisme!!!! Les bugs compliqués vont toujours arrivés, mais bcp moins souvent! Le test parfait n'existe pas, tout comme le code parfait. Les deux doivent constamment être refac Test proove presence of bugs, not absence. le goal c'est de se faire un parachute. 100% est impossible, mais 99.999 c'est déjà pas mal :) Si je te donne le meilleur code du monde, mais sans test, tu vas avoir peur de le changer et donc le code va pourrir. Si je te donne un code bif bof mais super bien tester, tu pourras le cleaner et donc le code va s'améliorer - Les tests qui font gagner des sous, mais qu'on fait moins: - Test de perf: Cfr amazon et ses bénéfices par second/millisecondes - Test d'ergonomie: Gagner des sous - A/B testing: Gagner des sous ------------- + cost of fixing http://www.seguetech.com/blog/2014/03/31/rising-cost-defects-2 http://www.jrothman.com/articles/2000/10/what-does-it-cost-you-to-fix-a-defect-and-why-should-you-care/ “We’ll fix that when we have time. In the meantime, just keep developing! How can you possibly tell how much it will cost to fix later?” — An Engineering manager, eager to continue software development “Let’s find all the defects before system test. The customer will wait for the product.” — An Engineering manager, concerned that shipping a product with defects would prevent customers from buying the product - Pouvoir le reproduire en DEV - Plus difficile de trouver la root cause que pendant la période de dev... Vu que t'es le nez dedans - Peu engendrer un refactoring ... Et c'est plus chaud de faire du refac sur un code déjà en prod + T'as plus le nez dedans (encore une fois) - Pendant que tu fix ton bug, tu ne crées RIEN - Et si le bug empeche de finaliser une vente? Ex: Toyota qui rappelle ses voitures, Une fusée qui explose - Et la réputation?

Importance of test automation, excuses and TDD introduction

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (10)

Similaire à Importance of test automation, excuses and TDD introduction

Similaire à Importance of test automation, excuses and TDD introduction (20)

Dernier

Dernier (20)

Importance of test automation, excuses and TDD introduction

Notes de l'éditeur