Propulsez votre architecture grâce au TDD et aux Mocks

FÉLIX-ANTOINE BOURBONNAIS

ING.JR, PSM, M.SC.

Agile Montréal

12 mars 2014

nas

a.go

v

© 2

01

4 Elap

se Techn

olo

gies

Image de Eyesplashhttp://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg

Félix-Antoine BourbonnaisIng. jr, PSM, M.Sc.

www.elapsetech.com

Formation – Accompagnement – Conseils

fbourbonnais@elapsetech.com

elapsetech.com/fab

@fbourbonnais

linkedin.com/in/fbourbonnais

Contact

Formateur et Coach Agile

Tests automatisés

TDDBDD et ATDD

Code propreQualité logicielle

Architecture AgileOrientation objet

Orientation aspect

Design testable et émergeant

ScrumAccompagnement d’équipesAgent de changement

© 2

01

4 Elap

se Techn

olo

gies

Avertissement

Cette présentation s’adresse principalement à un public ayant déjà

expérimenté le TDD mais aucune supervision n’est nécessaire pour en

profiter…

© 2

01

4 Elap

se Techn

olo

gies

Réchauffement…

Qui fait du TDD?

Qui utilise des Mocks?

Quelles sont vos attentes?

Images de Idea Go / freedigitalphotos.net et ameshng / Flickr.com

© 2

01

4 Elap

se Techn

olo

gies

DOUBLURES ET MOCKS

Rappel sur les

© 2

01

4 Elap

se Techn

olo

gies

Rappel: les tests unitaires

© 2

01

4 Elap

se Techn

olo

gies

Rappel: les Mocks

CUTTest

CUT

A

B

X

N

© 2

01

4 Elap

se Techn

olo

gies

Rappel: les mocks

CTest

C

A

B

X

N

© 2

01

4 Elap

se Techn

olo

gies

Rappel: les mocks

CTest

C

A’

B’

A’’

LanceIOException

Retourne[1]

© 2

01

4 Elap

se Techn

olo

gies

TDD

Rappels des fondements du

© 2

01

4 Elap

se Techn

olo

gies

Technique ou discipline?

Le TDD est une discipline

© 2

01

4 Elap

se Techn

olo

gies

Rappel: Le cycle du TDD

Écrire un test qui échoue

Faire passer le

testRéusiner

On passe à la phase « VERTE » dès qu’on a un test qui échoue.

Erreur de compilateur = « échec ».1

On passe à la phase « Réusinage » dès que le test passe.

2

1

© 2

01

4 Elap

se Techn

olo

gies

Shu-Ha-Ri

L’élève suit l’enseignement

d’un maître

SHU

Il apprend de d’autres

maîtres(écoles)

HA

Il suit et a sa propre pratique…

RI

Power de Jardson Araújo du The Noun ProjectKeikogi de Tiago Dos Reis Rodrigues duThe Noun Project

© 2

01

4 Elap

se Techn

olo

gies

TDD « CLASSIQUE »Le design et le

Image: posterize / FreeDigitalPhotos.net

© 2

01

4 Elap

se Techn

olo

gies

TDD classique

Centré sur l’étatet le résultat final

Image: nuchylee / FreeDigitalPhotos.net

© 2

01

4 Elap

se Techn

olo

gies

TDD classique

Extraction des types

ClasseP Classe

R1

PTest

Division

R1Test

ClasseP

PTest

MockR1

© 2

01

4 Elap

se Techn

olo

gies

TDD classique

En résumé

TDD Classique

Évolution du « design »

•Par division

•Extraction

Problèmes algorithmiques

•Traitement de données

•Calculs

Valide l’état

© 2

01

4 Elap

se Techn

olo

gies

L’ORIENTATION OBJET

Rappel de

© 2

01

4 Elap

se Techn

olo

gies

InfrastructureDomaineUI

Messages et collaboration

ClasseACtrl

Collaboration des objets fonctionnalité

ClasseB

ClasseC

IfaceE

ClassePersist

ClasseD

© 2

01

4 Elap

se Techn

olo

gies

Le « Tell don’t Ask »

getAmi(joe)

.getCorps()

.getJambe(Orient.GAUCHE)

.setPosition(

sol + 5,

centre + 20)

Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

Hein !?!

© 2

01

4 Elap

se Techn

olo

gies

Pourquoi le « Tell don’t ask »

Cacher le « comment »

Limiter l’effet des

modifications

Limiter l’effet d’avalanche

Réduire la duplication

Laisser les objets « s’occuper de leurs oignons »

Éviter les « domaines

anémiques »

© 2

01

4 Elap

se Techn

olo

gies

Stim

ulu

sUn objet est une boîte noire

Classe

Réception d’un message

Envoi d’un message à un collaborateur

Envoi d’un message à un collaborateur

Retour d’une réponse

Effe

t

Effe

t

…

© 2

01

4 Elap

se Techn

olo

gies

PILOTER SON DESIGN AVEC DES MOCKS?Comment

Image: jscreationzs / FreeDigitalPhotos.net

© 2

01

4 Elap

se Techn

olo

gies

Le TDD « Mockiste »

Centré sur les interactions et comportementsentre les objets considérant leur rôle

© 2

01

4 Elap

se Techn

olo

gies

Le TDD « Mockiste »

Utilise les Mocks comme pierre angulaire

Images: cooldesign/ freedigitalphotos.net

© 2

01

4 Elap

se Techn

olo

gies

TDD « Mockiste »

Extraction des types

Découverte des types par les MocksDéfinition de l’interface à partir des besoins établis dans les autres tests

© 2

01

4 Elap

se Techn

olo

gies

TDD piloté par les Mocks

Identifier les rôles

Viewer<<Interface>>

LoaderViewer

Test

Découverte pas à pas

ClassePNGLoader

PNGLoaderTest

<<Interface>>

FileReader

MockMock

?

?

Tirer les types à partir de la demande

© 2

01

4 Elap

se Techn

olo

gies

TDD piloté par les Mocks

Arriver à destination…

Testacceptation

Viewer

UTest

Terminé

<<Interface>>

Loader

ClassePNGLoader

Utest

<<Interface>>

FileReader

FakeFileReader

Utest

© 2

01

4 Elap

se Techn

olo

gies

En résumé

Quelle est la responsabilité de

l’objet testé ?

De quoi est-ce que l’objet a besoinpour réaliser son travail en terme de

rôles ?

Quels effets externes aura ce

comportement sur l’environnement immédiat?

Classe testée(CUT)

Responsabilité

A

Besoin de A (rôle)

B

Effet sur B

© 2

01

4 Elap

se Techn

olo

gies

Exemple

banque.acheter(carte, marchand, montant)

--> carte.crediter(montant)

--> marchand.debiter(montant)

© 2

01

4 Elap

se Techn

olo

gies

DÉMONSTRATIONPrésentation de la

Image: Stuart Miles / freedigitalphotos.net

© 2

01

4 Elap

se Techn

olo

gies

Démonstration

Soumissions à une conférence

#1 Soumission d’une présentation

En tant que soumissionnaireJe veux soumettre une présentation à une conférenceAfin qu’elle soit évaluée par le comité de sélection

Critères d’acceptation• Il est possible de soumettre une présentation• La présentation est accumulée en attendant d’être évaluée par le comité• Le comité est avisé qu’une nouvelle présentation doit être évaluée

© 2

01

4 Elap

se Techn

olo

gies

CONCLUSION et RÉSUMÉ

© 2

01

4 Elap

se Techn

olo

gies

Approche « outside-in »

Image: Simon Howden / FreeDigitalPhotos.net

UI

Domaine

Infrastructure

Duplication?

Réusinage

TDD

© 2

01

4 Elap

se Techn

olo

gies

Piloter le design par les mocks

Image: Simon Howden / FreeDigitalPhotos.net

UI

Domaine

Infrastructure

MyLibraryView

…Presenter

OnlineLibrary Book

LibraryProvider

LibraryRealTimeView

…Presenter

OnlineService

Mock

Mock

Composer à partir des interactions

Position « utilisateur »

Explorations successives(étape par étape)

Reporter les décisionsd’implémentations

Explorer sans trop se compromettre

© 2

01

4 Elap

se Techn

olo

gies

Avantages de l’approche mockiste

Favorise le« Tell don’t ask »

Moins de « trains d’appels »

(Demeter)

Retarde les décisions d’implémentations

Favorise un design testable

Requiert moins d’objets

implémentés pour avoir une rétroaction

Classe fautive ciblée en cas d’échec

© 2

01

4 Elap

se Techn

olo

gies

Avantages de l’approche mockiste

Développement piloté par les besoins (need-driven)

Définir les interfaces à partir des appelants

Focalise sur le « Quoi » avant le « Comment »

© 2

01

4 Elap

se Techn

olo

gies

Ce que l’on obtient généralement

Hiérarchie minceDesign basé sur

les rôlesAbstraction

(rôles)

Nommage clair pour l’appelant

Possible meilleur respect des

principes OO

© 2

01

4 Elap

se Techn

olo

gies

Désavantages de l’approche mockiste

Couplage du test avec la signature

des collaborateursFragiliser les tests

Fonctionne mal avec des

problèmes algorithmiques

Peut générer beaucoup de

Mocks et d’interfaces

Manquer de tests intégrés

(pyramide)

© 2

01

4 Elap

se Techn

olo

gies

La bonne question…

Que voulez-vous maximiser ?

© 2

01

4 Elap

se Techn

olo

gies

Complémentarité

Cette école doit être combinée!

Alterner entre les techniques

apporte généralement de bons résultats.

Choisir selon ce que l’on veut

découvrir

© 2

01

4 Elap

se Techn

olo

gies

Rappel: TDD et architecture

+ Code testable

+ de « design »

simple?

- de code couplé

+ de code réutilisable

+ d’architecture émergeante

© 2

01

4 Elap

se Techn

olo

gies

Pour aller plus loin…

Image de anamkkml/ FreeDigitalPhotos.net et github.com

Code sourcehttps://github.com/fbourbonnais/propulsez-architecture-tdd-mocks

Diapositiveshttp://developpementagile.com/architecture-mocks-tdd

Les tests en agilités

TDD pour gestionnaires

Introduction à l’ATDD et BDD

TDD avancé

TDD

Concepts OO avancés

Nos formations sur le sujet

www.elapsetech.com/formation

© 2

01

4 Elap

se Techn

olo

gies

Mer

ciMon nom

Félix-Antoine Bourbonnais

Notre bloguedeveloppementagile.com

Notre siteelapsetech.com

Mon Twitter@fbourbonnais

Mon LinkedInlinkedin.com/in/fbourbonnais/fr

© 2

01

4 Elap

se Techn

olo

gies

Elapse Technologies

Formation

Accompagnement (coaching)

Mentorat virtuel

Conseils et diagnostics

Agilité (Scrum, Lean, XP)

Qualité et tests automatisés

Architecture Agile

Pratiques de développement

Votre allié en développement logiciel Agile

© 2

01

4 Elap

se Techn

olo

gies

Références

© 2

01

4 Elap

se Techn

olo

gies

Références

Steve Freeman, Tim Mackinnon, Nat Pryce, et Joe Walnes. Mock roles, Not objects. p. 236–246. OOPSLA ’04. Vancouver, BC, Canada, ACM, 2004.

Nat Pryce, et Steve Freeman, InfoQ: Mock Roles Not Object States . QCon London 2007http://www.infoq.com/presentations/Mock-Objects-Nat-Pryce-Steve-Freeman

Martin Fowler, Mocks Aren’t Stubs, 2 janvier 2007. [Résumé des approches]http://martinfowler.com/articles/mocksArentStubs.html

© 2

01

4 Elap

se Techn

olo

gies

Références

Steve Freeman, Sustainable Test-Driven Development. QCon San Francisco 2009. http://www.infoq.com/presentations/Sustainable-Test-Driven-Development

Codemanship presents... Classic TDD vs. London School, 2011. [Critiqué]http://www.youtube.com/watch?v=AUE155LISV4

Michael Feathers et Steve Freeman. Michael Feathers and Steve Freeman on Design, InfoQ at QCon San Francisco 2009http://www.infoq.com/interviews/feathers-freeman-design

Discussion – « Classic TDD or « London School » - anyopinions/comments/elaboration on Jason Gorman’s post? » GOOS Mailinglist, 2011. https://groups.google.com/d/topic/growing-object-oriented-software/dOmOIafFDcI/discussion