L'apprentissage du TDD en coding-dojo. Xavier Nopre. 18/10/2013 Salle : Courage 10h30 12h30

Transcription

1 L'apprentissage du TDD en coding-dojo Xavier Nopre 18/10/2013 Salle : Courage 10h30 12h30

2 Merci à nos sponsors Platinium Gold Parrainage Silver Institutionnel

3 Qui suis-je? Xavier Nopre Développeur Agiliste xnopre.blogspot.com

4 Puis-je avoir ce diaporama? Un mail à : o Votre avis sur cette session o Vos questions

5 Programme (2h) Préambules : 5' Théorie et rappels : 20' o Tests unitaires, TDD, coding-dojo Pratiquons ensemble : 60' Démonstration avancée : 20' Questions / réponses : 15'

6 Préambule

7 Qui êtes-vous? Vous êtes : Développeur? ScrumMaster ou Product Owner? Manager? Formateur / coach? Autre?

8 Votre connaissance en agilité? Je découvre, je n'y connais rien Je connais les bases, je ne pratique pas encore Je pratique un peu Je pratique régulièrement (ex: un des rôles de Scrum) Je maitrise, j'explique, je forme et accompagne

9 Votre pratique des TU et du TDD? Je découvre, je n'y connais rien Je sais ce que c'est mais sans pratiquer J'ai essayé les tests unitaires le TDD Je fais des tests unitaires après le code de prod Je pratique le TDD régulièrement Tout ça ne sert à rien! Autre?

10 Tests unitaires

11 De quoi parlons-nous? Tests unitaires = Du code qui teste du code

12 Coût des tests unitaires? Quel surcoût pour les tests unitaires? Quel surcoût pour le TDD?

13 Pourquoi des tests unitaires et du TDD? TDD Agilité Qualité Développement incrémental Répondre au besoin Architecture évolutive Tests autres Tests unitaires Code testable Accepter le changement Refactoring sans régressions - Intégration continue - Automatisation

14 Tests unitaires = la base des tests Tests manuels Tests GUI Tests intégration / acceptance Test unitaires Les tests unitaires sont la "base" de tous les tests L'investissement et le volume sont plus importants pour les TU Tous les types de tests sont complémentaires Pyramide des tests Mike Kohn

15 Tests unitaires = limiter les coûts des anomalies

16 Rappels sur les tests unitaires Simples ("unitaires") Lisibles Rapides à écrire Rapides à exécuter Indépendants (des autres) Autonome (/ environnement) Répétables Auto-suffisants Automatisables Parallèlisables Pas forcément partout (pensez ROI) Structurés o Préparations o Test (1 action) o Vérifications Tests de "classe" sur l'api publique de la classe Bon outillage

17 TDD = "Test Driven Development"

18 TDD pourquoi? Vérifier la compréhension du besoin fonctionnel et être sûr d'y répondre Traduction des specs en tests Détecter au plus tôt des problèmes dans les specs : oublis, impressions, contradictions, Générer du code testable Systématiser la présence de tests unitaires, améliorer la couverture du code par les tests Les tests sont plus "faciles" à écrire avant le code de production que après

19 Les débuts sont difficiles L'apprentissage est long Oui, mais C'est un investissement, qui doit être collectif (équipe) Mais ROI important!

20 Remaniement et mise au propre du code, de l'architecture, de la présentation, factorisation, commentaires, Refactoring Ecriture du test Le cycle du TDD Ecriture d'un test et un seul et s assurer qu il ne passe pas pour de bonnes raisons Ecriture du code de production Ecriture du code minimum pour faire passer ce test

21 Coding-dojo

22 Coding-dojo : introduction Apprentissage d'un sport de combat vs Apprentissage en développement logiciel (langage, techno, conception, )

23 Coding-dojo : Quoi? Pour qui? C est quoi? : Un lieu d entrainement, d échanges, d amélioration Un espace «sécurisé» Un travail collectif, de collaboration, pas de compétition Un moment convivial, où tout le monde doit participer C est pour qui? : Pour les développeurs volontaires et motivés Pour tous les niveaux

24 Coding-dojo : Kata et Randori Kata : "Démonstration" 1 personne présente 1 solution Objectif : montrer (technique, techno) Tout le monde doit suivre, on peut interrompre Randori : "Travail de dév en groupe" Résolution (partielle) collective d'un défi Objectif : apprendre, échanger, s'entrainer, tester, se tromper, Pas besoin d'aller au bout A consommer sans modération!

25 Coding-dojo : Randori : Organisation 1 poste de travail, vidéo-projeté 2 personnes en pair-programming : "pilote" & "copilote" On tourne d 1 personne toutes les 5 à 7 (copilote pilote) 1 animateur : vérifie le respect des règles, tranche les décisions, met l accent sur les pratiques (bonnes ou mauvaises) Interventions des participants : o Les participants doivent comprendre et peuvent questionner o Sinon, les participants n interviennent que lorsque c est «vert» Rétrospective!

26 Etre courageux : Coding-dojo : Randori : Conseil o Etre capable de programmer devant les autres = hésiter, tâtonner, se tromper, réussir! o Accepter la critique, être prêt(e) à se remettre en question o Accepter de voir son travail repris, modifié, supprimé Etre généreux : o Expliquer sa démarche, sa solution, ses choix o Montrer ses «trucs et astuces» Etre tolérant

27 A nous de jouer! Sujet : "Tennis (scoring) Kata" Générateur de score de tennis

28 Précisions : architecture (P-n-OO) Game : - - xxx - - xxx Score (Texte) Tennis Score Builder Légende : Bean de données (POJO) Traitement

29 "Users Stories" 2-1 "30-15"

30 C'est parti!

31 TDD : pas seulement du "test first" Plus qu'une pratique une discipline o Pas d'ajout de code sans test rouge Plus qu'une méthode de tests une activité de conception Etat d'esprit Une approche addictive Partie intégrante de la pratique de développement logiciel!

32 Mocks

33 Les Mocks Collaborateur Collaborateur Classe à tester Collaborateur 1 rôle! Collaborateur

34 Les mocks : sujet de démo Pilote pour ouvrir des barrières : o Driver o openbarrier(2) o Envoyer une trame "OB2"

35 Les mocks : architecture pour la démo opengate Driver Numéro encode Encoder Trame transmit Connector Légende : Bean de données (POJO) Traitement pur Traitement pur"aiguillage"

36 Les mocks : démo!

37 Agile Tour Montpellier 2013 Travailler ensemble, autrement Merci! Des questions?