TDD en coding-dojo -...
Transcript of TDD en coding-dojo -...
-
TDD en coding-dojo
Xavier Nopre
-
Merci à nos partenaires
et sponsors
13/11/2014
-
Puis-je avoir ce diaporama ?
Un mail à [email protected] :
– Votre avis sur cette session
– Vos questions
-
Qui suis-je ?
Artisan-programmeur Agiliste
Indépendant
Xavier Nopre
• Développement d'applications "sur-mesure" pour des clients finaux
• Interventions en entreprises : formation, accompagnement, développement freelance
@xnopre xnopre.blogspot.com
https://twitter.com/xnoprehttp://xnopre.blogspot.com/https://twitter.com/xnoprehttps://twitter.com/xnoprehttp://xnopre.blogspot.com/http://fr.viadeo.com/fr/profile/xavier.noprehttp://www.linkedin.com/nhome/
-
Programme (2h)
• Préambules : 10'
• Théorie et rappels : 30'
– Tests unitaires, TDD, coding-dojo
• Pratiquons ensemble : 60'
• Démo mock : 10'
• Questions / réponses : 10'
-
Préambule
-
Qui êtes-vous ?
Vous êtes :
• Développeur ?
• ScrumMaster ou Product Owner ?
• Manager ?
• Formateur / coach ?
• Autre ?
-
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
-
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 !
-
Tests unitaires
-
De quoi parlons-nous ?
Tests unitaires =
• Du code qui teste du code
-
Coût des tests unitaires ?
• Quel surcoût pour les tests unitaires ?
• Quel surcoût pour le TDD ?
-
Pourquoi des tests unitaires et du TDD ?
Agilité
Répondre au besoin
Tests unitaires
Tests autres
Code testable
- Architecture Évolutive - Refactoring sans régressions
TDD
Qualité
- Développement Incrémental - Accepter le changement - Intégration continue
- Automatisation …
-
Tests unitaires = la base des tests
Test unitaires
Tests intégration / acceptance
Tests GUI
Tests manuels
Pyramide des tests – Mike Cohn
• 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
-
Tests unitaires = limiter les coûts des anomalies
€
€€€
-
Rappels sur les tests unitaires
• Simples ("unitaires")
• Lisibles
• Rapides à écrire
• Rapides à exécuter
• Indépendants (des autres)
• Autonome (/ environnement)
• Répétables
• Automatisables
• Parallèlisables
• Pas forcément partout … (pensez ROI)
• Structurés – Préparations
– Test (1 action)
– Vérifications
• Tests de "classe" sur l'API publique de la classe
• Bon outillage
• …
-
TDD =
"Test Driven Development"
-
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
-
Oui, mais …
• Les débuts sont difficiles
• L'apprentissage est long
• C'est un investissement, qui doit être collectif (équipe)
• Mais ROI important !
-
Le cycle du TDD
Ecriture du test
Ecriture du code de production
Refactoring
Ecriture d'un test et un seul et s’assurer qu’il ne
passe pas pour de bonnes raisons
Ecriture du code minimum pour faire passer ce test
Remaniement et mise au propre du code, de l'architecture, de la
présentation, factorisation, commentaires, …
-
Coding-dojo
-
Coding-dojo : introduction
Apprentissage d'un sport de combat
vs
Apprentissage en développement logiciel
(langage, techno, conception, …)
-
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
-
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 !
-
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 : – Les participants doivent comprendre et peuvent questionner
– Sinon, les participants n’interviennent que lorsque c’est « vert »
• Rétrospective !
-
Coding-dojo : Randori : Conseil
• Etre courageux : – Etre capable de programmer devant les autres = hésiter, tâtonner, se
tromper, … réussir !
– Accepter la critique, être prêt(e) à se remettre en question
– Accepter de voir son travail repris, modifié, … supprimé
• Etre généreux : – Expliquer sa démarche, sa solution, ses choix
– Montrer ses « trucs et astuces »
• Etre tolérant
• …
-
TDD : pas seulement du "test first"
• Plus qu'une pratique une discipline – 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 !
-
A nous de jouer !
Sujet :
"Tennis (scoring) Kata"
Générateur de score de tennis
-
Précisions : architecture (P-n-OO) et stateless
Tennis
Score Builder
Game :
- - xxx - - xxx
Score
(Texte)
Bean de données (POJO) Traitement Légende :
-
"Users Stories"
2-1
"30-15"
-
C'est parti !
-
Mocks
-
Les Mocks
Classe à tester
1 rôle !
Collaborateur Collaborateur
Collaborateur
Collaborateur
-
Les mocks : sujet de démo
Jeu de tennis : GUI & Controller !
-
Controller
Les mocks : architecture pour la démo
Bean de données (POJO) Traitement pur Légende :
Game
ScoreBuilder
click
composeScore(Game)
Gui
playerxHasScored()
Traitement pur"aiguillage"
displayScore(String)
-
Les mocks : démo !
-
Merci !
Questions ?