Design + tests (TDD)

Mockito inside.

TDD ; en général

C’est quoi le TDD ?

=> Test Driven Development

Quels avantage à cette pratique ?

précise les spécifications du code

permet d’utiliser le programme avant qu’il soit même

écrit

augmente la confiance pour le refactoring

valide la conformité du code

TDD ; pour le design

Quels avantages à plus long terme ?

Moins de bugs techniques + plus de bugs

métier, sur les specs.

Évolutivité et maintenance moins

couteuse.

Confort du code

TDD ; une évolution de la pratique

dans le temps

Débutant Expérimenté

Spécifications &

exigences

Codage du test

Codage des

fonctionnalités

Intéressé par la

conformité

… specs / exigences /

conformité

Design du code

Design du test

API

TDD ; une évolution de la pratique

dans le temps

Débutant Expérimenté

Spécifications &

exigences

Codage du test

Codage des

fonctionnalités

Intéressé par la

conformité

… specs / exigences /

conformité

Design du code

Design du test

API

Un bon design

Dans un langage objet

Pour quelle audience ?

Comment y arriver ?

Avec quels outils ?

Dans un langage OO

À quoi somme nous habitué ?

À un graphe d’objet Construction hiérarchique de structure

Très souvent une structure de données seules qui est baladé par d’autres objets sans état. => Transaction Script

Nous sommes habitués à une approche ontologique dans le design d’un système.

The big idea of object oriented

programming The big idea is "messaging"

The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.

Alan Kay

Un des père de la programmation orientée objet, un des père de SmallTalk

Mockito permet de se focaliser sur les interactions

Pour quelle audience ?

Un bon design ok, mais qui est

intéressé ?

Est-ce que les intérêts sont les mêmes

?

Pour les auteurs?

Pour les utilisateurs ?

Pour quelle audience ?

Un bon design ok, mais qui est intéressé, qui devrait être intéressé ? Dev, Archi, Manager, Client

Est-ce que les intérêts sont les mêmes ? Pour les auteurs?

○ Dev de framework / lib : Favoriser l’extensibilité, la réutilisation, le confort, facile à corriger

Pour les utilisateurs ? ○ Utiliser un code facile à comprendre, facilement

extensible, corrigeable

Pour quelles audiences ?

Pour un dev de lib / de framework En particulier pour le développement Open Source, problème

du temps libre !

On a les même problèmes qu’un manager sur le cycle de vie d’un projet : le temps c’est de l’argent

Pour l’utilisateur, un bon design lui fait gagner en efficacité API lisible et expressive (!= verbeux) ; un développeur passe

en général plus de temps à lire du code qu’a en écrire!

API ouverte aux extensions, plus facile à developper, remplacer du code

Le dev d’une lib ou d’un framework doit aussi être utilisateur de celle-ci. Le test aide très tôt dans le développement.

Avec quels outils ?

Avec quels outils ?

Pourquoi Mockito plus que les autres ? Framework de mock avec une API simple et propre

Rapport d’erreur de premier ordre

Support de l’approche BDD

Super javadoc

Pleins de features

Easymock API plus verbeuse, et un peu plus intrusive

Moins de features

Powermock Très bon framework, mais plus complexe à mettre en œuvre (pour

l’auteur et pour les utilisateurs)

Dangereux pour le design : tests boite blanche

OK pour le legacy

L’auteur lui-même recommande Mockito

Améliorer le design

Le design est une approche pour contrôler la complexité d’un projet

Ses outils : patterns et principes ○ GRASP

○ GoF

○ SOLID

Aux anti-patterns et lois ○ Par ex : The Law of Leaky Abstractions

Améliorer le design

Petit focus sur ‘High Cohesion’ C’est avoir des méthodes qui ont en commun un ou quelques

concepts seulement

Cette mesure s’appelle LCOM ○ Si elle est trop haute => refactoring (découpage des

fonctionnalités, introduction de collaborateur, …)

Low Coupling Couplage : C’est d’avoir trop de dépendances

○ Imports, Paramètres

Mais pas que : ○ Héritage, Temporel, Flow

Impact fort sur les tests ○ En TDD le couplage rajoute très vite de la pénibilité => refactoring

Améliorer le design

Les closures

Petits objets facilement externalisables

Facilement testables

Sur les clients de ces closures.

Moins de chose à tester parce que

○ le reste du code est testé

○ surtout ce n’est plus sa responsabilité (SRP)

Améliorer le design

Donnez un peu d’amour aux tests

Si vous refactorez, pensez à alléger vos test

relaxer le test

se focaliser sur le scénario du test ET la responsabilité du code testé

Pour vos objets de données Pattern des Value Object en DDD (instanciable avec un

constructeur)

Factory Method accountWith("bob", "lee", 100023348.23D)

Builder à la Joshua Bloch

Améliorer le design

Les tests aussi ont leurs anti-patterns aka Test Smell James Carr en a fait une liste

○ Excessive Setup

○ The Liar

○ The Free Ride

○ …

Pour les mocks ○ The Mockery

○ Don’t mock value object

○ Don’t mock types you don’t own

Publicité

À lire + sources

Anti-patterns de test par James Carr http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/

Growing Object Oriented Software Guiged by Tests http://www.amazon.fr/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

Échanges sur Hotspot en 98 avec Alan Kay http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

Étude de productivité de logiciel OO http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf

Étude sur la productivité et l’efficacité avec les langages objet http://www.sciweavers.org/publications/study-productivity-and-efficiency-object-oriented-methods-and-languages

Don’t mock types you don’t own http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html