TDD en coding dojo - Agile Tour Montpellier

L'apprentissage du TDD
en coding-dojo
Xavier Nopre
www.twitter.com/xnopre
xnopre.blogspot.fr
[email protected]
Merci à nos sponsors
Platinum
Silver
Gold
Institutionnel
Puis-je avoir ce diaporama ?
Un mail à [email protected] :
– Votre avis sur cette session
– Vos questions
Qui suis-je ?
Xavier Nopre
Artisan-programmeur
Agiliste
Indépendant
• Développement d'applications "sur-mesure" pour
des clients finaux
• Intervention en entreprises : formation,
accompagnement, développement freelance
@xnopre
xnopre.blogspot.com
Programme (2h)
14h-16h :
• 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
?
TDD
Qualité
Agilité
Répondre
au besoin
- Développement
Incrémental
- Accepter le
changement
Tests autres
- Architecture
Évolutive
- Refactoring
sans régressions
Tests
unitaires
Code
testable
- Intégration continue
- Automatisation
…
Tests unitaires = la base des tests
Tests manuels
Tests
GUI
Tests intégration
/ acceptance
Test unitaires
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
Remaniement et mise au
propre du code, de
l'architecture, de la
présentation, factorisation,
commentaires, …
Ecriture d'un test et un
seul et s’assurer qu’il ne
passe pas pour de
bonnes raisons
Refactoring
Ecriture du
test
Ecriture du code
de production
Ecriture du code minimum
pour faire passer ce test
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 :
Randori :
• "Démonstration"
• 1 personne présente 1
solution
• Objectif : montrer
(technique, techno)
• Tout le monde doit suivre,
on peut interrompre
• "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
Game :
- - xxx
- - xxx
Tennis
Score
Builder
Score
(Texte)
Légende :
Bean de données (POJO)
Traitement
"Users Stories"
2-1
"30-15"
C'est parti !
Mocks
Les Mocks
Collaborateur
Collaborateur
Classe à
tester
1 rôle !
Collaborateur
Collaborateur
Les mocks : sujet de démo
Jeu de tennis : GUI & Controller !
Les mocks : architecture pour la démo
click
Controller
playerxHasScored()
Gui
Game
displayScore(String)
composeScore(Game)
ScoreBuilder
Légende :
Bean de données (POJO)
Traitement pur
Traitement
pur"aiguillage"
Les mocks : démo !
Merci !
Questions ?
Agile Tour Montpellier 2014
Scaling Agile
www.agiletour-montpellier.fr
www.bit.ly/19gwDwl
www.twitter.com/atmtp
[email protected]