Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable

Preview:

DESCRIPTION

Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.

Citation preview

TDD, le meilleur moyen d'écrire du code testable

Xavier Nopre

Puis-je avoir ce diaporama ?

Un mail à xnopre@gmail.com :

– 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

Tests unitaires

De quoi parlons-nous ?

Tests unitaires =

Du code qui teste du code

Tests unitaires et agilité ?

Agilité :

• Développement itératif et incrémental

• En permanence, adapter le code existant pour ajouter de nouvelles fonctionnalités = refactoring

• Sans régression Nécessité de filets de sécurité

• Tests unitaires et autres

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)

• Répétables

• Automatisables

• Pas forcément partout … (pensez ROI)

• Structurés – Préparations

– Test (1 action)

– Vérifications

• 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)

• Plus facile avec formation & accompagnement

• 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, …

Démo time !

Régles du coding-dojo "kata"

• Démonstration :

– D' 1 solution

– À 1 défi

– Par 1 personne

• Objectif : montrer

• Tout le monde doit suivre et comprendre on peut interrompre

Sujet

• Issu de l'atelier "Elephant Carpaccio exercise"

• Calcul de prix avec remises : (PU ; Quantité) prix

• Remises :

Valeur commande Réduction

1 000 € 3 %

5 000 € 5 %

7 000 € 7 %

10 000 € 10 %

Je réfléchis à mes tests …

// doit_appliquer_un_prix_sans_remise

// 3 (1.25) --> 3,75

// doit_appliquer_une_remise_de_3_pourcents_si_plus_de_1000

// 100 (12.10) --> 1173.70

// doit_appliquer_une_remise_de_5_pourcents_si_plus_de_5000

// 500 (12.10) --> 5747.50

// doit_appliquer_une_remise_de_7_pourcents_si_plus_de_7000

// 700 (12.10) --> 7877.10

C'est parti !

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 !

Mocks

Les Mocks

Classe à tester

1 rôle !

Collaborateur Collaborateur

Collaborateur

Collaborateur

Les mocks : sujet de démo

Jeu de tennis : GUI & Controller !

Les Mocks

Controler

Game

GUI

ScoreBuilder

buttonPlayer1Pressed()

player1Scored()

computeScore(game)

"15-0"

displayScore("15-0")

Le 1er test avec les mocks

• Etant donné (Given) :

– Un "Controler" et ses collaborateurs

• Lorsque (When) :

– J'appelle la méthode "button1HasBeenClicked"

• Alors (Then) :

– La méthode "displayScore("?")" est appelée

Les mocks : démo !

Conclusion ?

• Tests unitaires (et ingénierie agile) : indispensables à l'agilité

• TDD : "le meilleur moyen d'écrire du code testable" (et testé), et générer une bonne architecture

• Apprentissage long et difficile : Formation et accompagnement S'entrainer, s'entraider ROI garanti !

Merci !

Questions ?

xnopre@gmail.com

Recommended