Les TDD en toute agilité

Printemps Agile 2015

Présenté par Pierre-Olivier BLOUIN @poblouin et Julien ANNE @Julien_ANNE
des Laboratoires Gilbert

Intro

  • Contexte
  • Retour de notre expérience au quotidien
  • À reproduire ou pas ;)

Avant de commencer ...

  • Sondage
  • Présentation Q&R
  • Live coding (rails)
  • Application de commandes de produits

TDD késako ?

Test Driven Development : technique de développement guidée par des tests (ex : unitaires, fonctionnels ...)

Qu'est ce qu'un test ?

"En programmation informatique, le test [...] est un [morceau de code] permettant de vérifier le bon fonctionnement d'une partie d'un logiciel (...)"

Source : Wikipédia

code

Pourquoi faire des tests ?

Pourquoi faire des tests ?

  • Bonne pratique
  • Non régression du code
  • Avoir un code de qualité
  • Une fonctionnalité à la fois : aller à l'essentiel !
  • Grosse évolution ? No problemo ! (refactoring)

Qui écrit les tests ?

  • Les développeurs
  • Les "testeurs"

Les différents types de tests

Les tests de controllers

Simulation des appels des actions des controllers

Ex : traitement formulaire (paramètres), redirection et/ou droits d'accès

Les tests de models

Simulation des appels aux méthodes des models (classes) de l'application

Ex : Vérifier que l'appel de la méthode "nombre_produits" sur une commande qui possède deux produits retourne bien 2

Un test, comment ça se présente ?

De quoi se compose un test ?

Un test se compose de code à exécuter, de données d'entrée (fixtures) et d'un résultat attendu (toujours le même)

Comment écrire un test ?

Le Product Owner nous demande d'implémenter la fonction "ajouter produit"

Comment exécuter un test ?

Il faut un lanceur de test

Ex : Rake, JUnit, PHPUnit etc ...

Que nous retournent les tests ?

  • Des erreurs
  • Des failures
  • Des assertions
code

Ça nous donne ...

  1. Le PO nous demande "total commande"
  2. On écrit le test
  3. On fait passer le test
  4. On refactor (et on vérifie qu'il passe toujours)

Quelles raisons peuvent faire échouer un test ?

Plusieurs ...

Le code de l'application ne répond pas au besoin

Les données d'entrée ne correspondent pas au cas testé

Le code des tests ne réalise pas le test souhaité

Renommage d'un champ en BDD

Toutes les fonctionnalités méritent-elles d'être testées ?

Ça dépend ! (héhé)

Peut-on tester tous les cas pour une fonctionnalité ?

Bien souvent il y a une infinité de cas possibles en fonction des données d'entrée

Ex : total commande avec des montants de produits allant de 0 à l'infini

Quel cas testons-nous ?

Tous les cas aux limites

Un ou plusieurs cas standards

DEMO

Quels sont les avantages des TDD au sein d'une équipe agile ?

Les avantages ...

  • Non régression du code écrit par un coéquipier
  • Appréhender plus rapidement l'application (les tests donnent des exemples, pas besoin de doc)
  • Avoir une vision de l'avancée du projet
  • Les tests sont "écrits" (non remis à plus tard)
  • Satisfaction du développeur
  • Compatibilité BINOMAGE !
  • Refactoring

Les inconvénients ...

  • Temps d'apprentissage
  • Mise en place (technique)
  • Changer ses habitudes
  • Bien comprendre la demande du PO
  • Equipe = règles communes (communication)

ROI !

"Ça va m'coûter combien cette histoire ..."

"... et combien ça rapporte ?"

Pour un projet :

(schema by Scott Ambler)

Démo (live coding)

THE END

Des questions ?