propulser votre architecture grâce aux mocks

Propulsez votre architecture grâce aux mocks

Confoo 2012

Montréal, Québec, Canada

2 mars 2012

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

!   Formateur et Coach Agile

!   Enseignement et formaKons o  TDD, Réusinage, OO avancé, AOP, tests, Scrum

!   Recherches o  AOP, agilité, tests et mocks

!  Développeur o  Java et Python (principalement)

2

@Uourbonnais

Réchauffement…

Quelles sont vos aXentes?

Qui fait du TDD?

Qui uKlise des Mocks?

3

Comment découvrir l’architecture?

TDD

Mocks

J’uKlise déjà des mocks!

Image: graur codrin / FreeDigitalPhotos.net

On va parler des mocks pour piloter la découverte du design!

TESTS IntroducKon aux

Plusieurs types de tests

Unitaire

Système

Bout-‐en-‐bout AcceptaKon

IntégraKon

…

Images: Renjith Krishnan, Salvatore Vuono, Jscreationzs, Photostock, Posterize / FreeDigitalPhotos.net

Tests unitaires But: tester les modules en isola*on.

DOUBLURES ET MOCKS IntroducKon aux

FoncKonnement

Module 3 : Tests unitaires Techniques et outils ! Mocks

FonctionnementSystème

(c) 2008-2009 F.-A. Bourbonnais et G.-E. Legendre, (c) 2010 F.-A. Bourbonnais. Contrôle de la qualité et métriques du logiciel GLO-4002 Automne 2010 39 / 60

10

FoncKonnement


FonctionnementIsoler


11

FoncKonnement


FonctionnementMocks


12

UKlisaKons

•  Simuler un cas précis dans un objet uKlisé par l’objet testé.

•  Exemple: Simuler une excepKon lancée.

Piloter (simuler un cas)

•  Vérifier que l’objet testé a eu l’effet désiré sur un autre objet.

•  Exemple: Vérifier que la méthode a été appelée sur un autre objet.

Vérifier un comportement

13

TDD IntroducKon au

Cycle du TDD

Écrire un test qui échoue

Faire passer le

test Réusiner

15

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

Pourquoi faire du TDD

16

La peur du changement…

Image: David CasKllo Dominici / FreeDigitalPhotos.net

Peur = î maintenabilité

Focaliser sur le « QUOI »

17

« Instead of just using tesKng to verify our work aker it’s done, TDD turns tesKng into a design ac*vity. [1] »

« We use the tests to clarify our ideas about what we want the code to do. [1]»

Se placer en posiKon d’uKlisateur du code

Se concentrer sur le « QUOI »

[1] Steve Freeman et Nat Pryce. Growing Object-‐Oriented So2ware, Guided by Tests. Addison-‐Wesley Professional, 1 ediKon, Octobre 2009.

TDD et architecture

!   Favorise l’écriture de code testable !  Offre une rétroacKon concernant la facilité d’uKlisaKon du « design »

!   Favorise l’écriture de code faiblement couplé

!   Favorise l’écriture de code réuKlisable !   Favorise l’évoluKon de l’architecture et la découverte progressive o  Colle à la réalité et aux besoins présents

L’ORIENTATION OBJET Rappel de

Infrastructure Domaine UI

Messages et collaboraKon

Classe A

Collabora*on des objets à fonc*onnalité

Classe B

Classe C

Classe E

Classe F

Classe D

Le « Tell don’t Ask »

Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

Pourquoi le « Tell don’t ask »

!   Cacher le « comment »

!   Limiter l’effet des modificaKons à la logique (algorithme)

!   Éviter les « trains » d’appels !   Réduire la duplicaKon !   Laisser les objets « s’occuper de leurs oignons » !   Éviter les « domaines anémiques »

SKmulus

Un objet est une boîte noire

Classe

RécepKon d’un message

Envoi d’un message à un collaborateur

Envoi d’un message à un collaborateur

Retour d’une réponse

Effet

Effet

TDD « CLASSIQUE » Le design et le

Image: posterize / FreeDigitalPhotos.net

TDD classique

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

Image: nuchylee / FreeDigitalPhotos.net

TDD classique ExtracKon des types

Classe P Classe

R1

PTest

Division

R1Test

Classe P

PTest

Mock R1

PILOTER SON DESIGN AVEC DES MOCKS?

Comment

Image: jscreationzs / FreeDigitalPhotos.net

TDD piloté par les Mocks Tirer à parKr des besoins

A

Tirer les types à parKr de la demande

B

C

Capacité de B et C (services) Besoins de A

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

Viewer <<Interface>> Loader

ViewerTest

Découverte pas à pas

Classe PNGLoader

PNGLoaderTest

<<Interface>> FileReader

Mock Mock

?

?

Tirer les types à parKr de la demande

TDD piloté par les Mocks Arriver à desKnaKon…

Test acceptaKon Viewer

UTest

Terminé

<<Interface>> Loader

Classe PNGLoader

Utest

<<Interface>> FileReader

Fake FileReader Utest

ÉvoluKon du design

Réusinage

•  InteracKons •  Signatures • …

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)

Avantages

!   Favorise le respect du « Tell don’t ask » !   Permet de définir les interface à parKr des besoins

o  Force à se concentrer sur le « Quoi » avant le « Comment »

o On définit d’abord le « Quoi » à parKr des tests des autres

!   Retarde les décisions d’implémentaKons

!   Favorise un design testable !   L’isolaKon favorise le réusinage

33

Ce que l’on obKent généralement

!  Hiérarchie mince

!  Design basé sur les rôles !  AbstracKon (sous la forme de rôles)

!  Nommage en posiKon d’uKlisateur o Méthodes et types

!  Meilleur respect du « Tell don’t ask »

!   Parfois moins de temps en déverminage pour trouver le problème lorsqu’un test ne passe plus

Désavantages

!  Ne permet pas d’établir le « comment »

!   Peut résulter en une trop grande séparaKon o  Trop de classes/interfaces

!   FoncKonne moins bien sur les systèmes basés sur les données

35

Approche « top-‐down »

UI

Domaine

Infrastructure

Image: Simon Howden / FreeDigitalPhotos.net

DuplicaKon?

Réusinage

TDD

Piloter le design par les mocks

UI

Domaine

Infrastructure

Image: Simon Howden / FreeDigitalPhotos.net

MyLibraryView

…Presenter

OnlineLibrary Book

LibraryProvider

LibraryRealTimeView

…Presenter

OnlineService

Mock

Mock

!   Composer à parKr des interacKons

!   PosiKon « uKlisateur » !   ExploraKons successives

(étape par étape)

!   Reporter les décisions d’implémentaKons

!   Explorer sans trop se compromeXre

Favoriser la détecKon des mauvaises odeurs... !   Beaucoup de Mocks

o  Couplage…

!  Difficile d’injecter les Mocks o  Pourquoi les dépendances ne sont pas passées? o  Patron « Factory »?

!   Paramètres mulKples (constructeurs et méthodes) o  ExtracKon d’un concept?

!   Incapable de trouver un nom

!   Etc.

DÉMONSTRATION PrésentaKon de la

Complémentarité

!   CeXe 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)

40

Téléchargement

Image: rajcreationzs / FreeDigitalPhotos.ne 41

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

Évaluez la présentaKon sur: hXps://joind.in/6106

QUESTIONS Période de

42

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 hXp://www.infoq.com/presentaKons/Mock-‐Objects-‐Nat-‐Pryce-‐Steve-‐Freeman

!   MarKn Fowler, Mocks Aren’t Stubs, 2 janvier 2007. [Résumé des approches] hXp://marKnfowler.com/arKcles/mocksArentStubs.html

Références !   Steve Freeman, Sustainable Test-‐Driven Development. QCon San Francisco

2009. hXp://www.infoq.com/presentaKons/Sustainable-‐Test-‐Driven-‐Development

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

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

!   Discussion – « Classic TDD or « London School » -‐ any opinions/comments/elaboraPon on Jason Gorman’s post? » GOOS Mailinglist, 2011. hXps://groups.google.com/d/topic/growing-‐object-‐oriented-‐sokware/dOmOIafFDcI/discussion

propulser votre architecture grâce aux mocks

Technology