Développement piloté par les tests

Bob - Pyxis Technologies

Moi, quand j'ai commencé à bosser...

...ça se passait comme ça :

Quand j'y repense...

...on écrivait l'application plusieurs fois :-(

Quand j'y repense...

...on écrivait l'application plusieurs fois :-(

Quand j'y repense...

...on écrivait l'application plusieurs fois :-(

Quand j'y repense...

...on écrivait l'application plusieurs fois :-(

Ca marchait pas si mal

On faisait des nuits uniquement vers la finOn arrivait à reporter les fautes sur les clientsOn s'en sortait grâce aux avenants

Ah bien sur...

on était fatiguéon était stresséon croisait les doigts à chaque livraison...on envisageait sérieusement d'aller élever des chèvres

En plus...

...c'était la faute à personne

En plus...

...c'était la faute à personne

En plus...

...c'était la faute à personne

En plus...

...c'était la faute à personne

Autrement dit...

...la faute au client !

STOP !!!

C'était vraiment n'im-por-te quoi

Souvent, il y a eu un choc, un déclic...

Certains ont lu un livreD'autres ont pris une bière avec des amisPour d'autres ça a été la nuit de trop

Par exemple, il y a ceux...

...qui ont lu ce livre une première fois...

...puis une deuxième

...puis une troisième

...

Il y a aussi ceux...

...qui ont lu ce livre une première fois...

...puis une deuxième

...puis une troisième

...

Et il y a ceux...

...qui ont pris ça très au sérieux.

Et il y a ceux...

...qui ont pris ça très au sérieux.

Développement piloté par les tests

Bob - Pyxis Technologies

Une idée maîtresse

Faire collaborer les différents intervenants

Si on simplifie un brin...

...on rencontre principalement 3 types d'intervenantsCeux qui "spécifient"Ceux qui "codent"Ceux qui "testent"

Malheureusement, la plupart du temps

Ils ne parlent pas le même langageIls ne travaillent pas ensembleIls ne se connaissent parfois même pas

Retroussons nos manches !

Il faut les aiderà travailler ensembleà rendre le travail de chacun utileà se sentir ensemble dans cette aventureà prendre du plaisir ?

Bonne nouvelle !

On a inventé tout ce qu'il faut pour ça :-)

Et si on ne parlait plus de "tests"...

Une spécification évoque un comportement génériqueUn test décrit un exemple d'utilisationUn test peut être un programme qui exécute le code

...mais de spécifications exécutables ??

Contient des exemplesLiée au codeLieu de rencontre et d'échanges

Alors ? Test ou Spec ?

Vous les lancez pour vérifier une non-régression ? -> on dirait des tests

Vous les écrivez pour décrire un comportement attendu ? -> on dirait des specs

Test -Driven Development

Cela veut dire plusieurs chosesSpécifier les comportements via des exemplesLier les spécifications au code de productionEcrire des tests avant le codeEchanger des idées en écrivant des testsPartager un résultat attendu avant de coderFaire des tests les starsSe mettre d'accord sur ce que l'on veut puis coderCapitaliser les conversations dans des testsDocumenter l'utilisation d'un code dans des testsSe lever le matin et penser aux tests que l'on va écrireSe coucher le soir et penser aux tests que l'on a fait passer...

Vous entendrez souvent parler...

...du "cycle" du TDD

Une vision simple du cycle

1 : Testécrire un test et voir qu'il échoueil faut ajouter au code la valeur décrite dans le test

2 : Codefaire passer le test rapidement

3 : Refactoron n'ajoute pas de fonctionnalitéon améliore la qualité interne du code

TDD & Qualité

Qu'est-ce qu'un logiciel de qualité ?

TDD & Qualité

Quel est notre engagement en tant que professionnels de l'informatique ?

TDD & Qualité

"Faire émerger le modèle pendant le refactoring"Pendant un cours de TDD, les participants s'interrogent

Dois-je écrire des tests pour les classes qui émergent en refactoring ?Si je le fais, ne suis-je pas en train d'éluder le refactoring pour continuer ?

Que pensez-vous de ça ?

Et si je le dessine comme ça ?

ça vous rappelle quelque chose ?

"Test-Driven Scrum" ?

"Show me the code!"

"Show me the code!"

Merci

Bons tests ! ;-)