Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012)

Propulsez votre architecture
grâce au TDD et aux mocks

Agile Tour 2012

© 2012 Elapse Technologies
Québec, Canada

6 novembre 2012

Félix-Antoine Bourbonnais
Ing. jr, PSM-I

Formateur et Coach Agile
Spécialités
o Tests: TDD, ATDD, BDD, etc.

o Orientation objet avancée http://bit.ly/Qut7Fm

o Réusinage et qualité (Clean Code)
@fbourbonnais
o Agile Scrum
linkedin.com/in/fbourbonnais
Développement
o Architecture logicielle agile
o Java, Python, etc.
2

Réchauffement…
Quelles sont vos
attentes?

Qui fait du TDD?

Qui utilise des Mocks?

3

Comment découvrir l’architecture?

TDD
Mocks

DOUBLURES ET MOCKS
Introduction aux

Tests unitaires
But: tester les modules en isolation.


7
N
X
A

B
Fonctionnement

CUT
CUT
Test

8
N
X
A

B
Fonctionnement

CUT
CUT
Test

Fonctionnement

A’ A’’ A’’’

Retourne Lance Retourne

[1] IOException [1, 2, 3]
CUT
CUT
Test

D’

9

Rappels des fondements du

TDD

Cycle du TDD

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

Erreur de compilateur
= « échec ».

Faire
3 Réusiner passer le
test
2
On passe à la phase « Réusinage »
dès que le test passe.
11

Le design et le

TDD « CLASSIQUE »

Image: posterize / FreeDigitalPhotos.net

TDD classique

Centré sur l’état et le résultat final

Image: nuchylee / FreeDigitalPhotos.net

TDD classique
Extraction des types

Classe Division
P Classe Classe

P R1
Mock
R1

PTest PTest R1Test

Le TDD classique
Centré sur la logique
Évolution du « design »
o Par division

o Découverte des types par extraction
Avantages – « Détails et logique»
o Construit des composants très modulaires et faiblement
couplés
o Facilite la réutilisation

15

L’ORIENTATION OBJET
Rappel de

Messages et collaboration

Classe
C
Classe
B

Classe
Classe D
A
Classe Classe
E F

UI Domaine Infrastructure
Collaboration des objets  fonctionnalité

Le « Tell don’t Ask »

Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

Un objet est une boîte noire
Stimulus

Réception d’un message

Envoi d’un message à

un collaborateur

Effet
Classe
Envoi d’un message à
un collaborateur
Effet

Retour d’une réponse

Comment

PILOTER SON DESIGN AVEC DES
MOCKS?
Image: jscreationzs / FreeDigitalPhotos.net

Le TDD « Mockiste »
Centré sur les
o Interactions entre les objets
o Rôles et responsabilités

Utilise les Mocks comme pierre angulaire
Évolution du « design »
o Par le raffinement
o Découverte des types par les Mocks
o Définition de l’interface à partir des besoins établis dans
les autres tests grâce aux mocks.

22

TDD piloté par les Mocks
Identifier les rôles requis (dépendances) par le module testé

Viewer <<Interface>> <<Interface>>
Test
Viewer ? Loader FileReader

Mock
Mock
PNGLoader Classe
Test ?
PNGLoader

Découverte pas à pas

Tirer les types à partir de la demande

TDD piloté par les Mocks
Arriver à destination…

Test <<Interface>> <<Interface>>
acceptation
Viewer Loader FileReader

UTest

Utest
Classe Fake
Utest
PNGLoader FileReader

Terminé

En résumé
1. Établir quelle est la responsabilité de l’objet testé
2. De quoi est-ce que l’objet a besoin pour réaliser son travail
en terme de rôles?

3. Quels effets aura ce comportement sur l’environnement
immédiat?
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)

DÉMONSTRATION
Présentation de la

Soumissions à une conférence
Système pour gérer les propositions soumises à une
conférence
Story #1:

o Permettre la soumission d’une présentation
o Les présentations doivent être accumulées en attendant
d’être évaluées par le comité
o Notifier le comité à la réception

Approche « top-down »

UI

Réusinage

Domaine

Infrastructure TDD

Duplication?

Image: Simon Howden / FreeDigitalPhotos.net

Piloter le design par les mocks
MyLibraryView
LibraryRealTime Composer à partir des
View
interactions
…Presenter …Presenter
UI
Position « utilisateur »
Moc

k
OnlineLibrary Book Explorations successives
Moc
(étape par étape)
LibraryProvider k
Reporter les décisions
Domaine
d’implémentations
OnlineService
Explorer sans trop se
compromettre
Infrastructure

Image: Simon Howden / FreeDigitalPhotos.net

Avantages
Favorise le respect du « Tell don’t ask »
Permet de définir les interfaces à partir des besoins
o Force à se concentrer sur le « Quoi » avant le « Comment »

o On définit d’abord le « Quoi » à partir des tests des autres
Retarde les décisions d’implémentations
Favorise un design testable
L’isolation favorise le réusinage

30

Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur les rôles
Abstraction (sous la forme de rôles)

Nommage en position d’utilisateur
o Méthodes et types
Meilleur respect du « Tell don’t ask »

Désavantages
Moins adapté pour découvrir les détails
(le « comment »)
Peut résulter en une trop grande séparation

o Trop de classes/interfaces
Fonctionne moins bien sur les systèmes basés sur les
données et fortement algorithmiques

32

Complémentarité
Cette technique 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
(design ou algorithme)

33

TDD et architecture
Favorise l’écriture de code testable
Offre une rétroaction concernant la facilité
d’utilisation du « design »

Favorise l’écriture de code faiblement couplé
Favorise l’écriture de code réutilisable
Favorise l’évolution de l’architecture et la découverte
progressive
o Colle à la réalité et aux besoins présents

35

QUESTIONS
Période de

Téléchargement
Téléchargez les diapositives complètes sur
developpementagile.com

Image: rajcreationzs / FreeDigitalPhotos.ne 36

Références

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 2007
http://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

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 2009
http://www.infoq.com/interviews/feathers-freeman-design
Discussion – « Classic TDD or « London School » - any
opinions/comments/elaboration on Jason Gorman’s post? » GOOS
Mailinglist, 2011.
https://groups.google.com/d/topic/growing-object-oriented-
software/dOmOIafFDcI/discussion

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012)

Semelhante a Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012) (20)

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012)