Docteur BDD

Ou comment j’ai appris à ne plus m’en faire avec les tests

(et la doc!)

Merci à nos sponsors Platinum

Et merci à nos sponsors Gold et Silver

Guillaume Saint Etienne

• Développeur Senior .Net

• Artisan Logiciel / Software Craftsman • J’ai également été Architecte, Chef de Projet, Scrum Master,

Responsable d’Activité

• http://dotnetguru2.org/gse

• http://groups.google.com/group/craftsmen-france-

• Twitter : @guillaume_agile

TESTER

• Je teste

• Tu testes

• Il ou elle teste

• Nous testons

• Vous testez

• Ils ou elles testent

• … mais tu peux pas (tout) test

qu'est ce que je teste?

Mon logiciel…

Comment je vois mon logiciel

De ma vision du logiciel découle ma vision des tests

Acceptance = IHM?

• Et les règles métier?

• Et le stockage?

• Et les transmissions/flux?

• Les transactions? les services externes?

• La gestion des erreurs, des mises à jour… Faut-il à chaque fois que je lance tout mon logiciel pour n’en tester qu’une partie???

% Code de l’IHM

GOF, ca vous parle?

• Humble Dialog

• MVC

• MVP

• MVVM

• …

Alors, découpons

Comment tester cela?

On est passé de ca…

…à cà!

Et puis on m’a parlé de services…

Alors j’ai découpé en services

Ca me rappelle …

Heureusement, je travaille chez

J’ai voulu tester les « services »

Mais un service c’est pas simple

• Les dépendances m’ont tuer!

A l’intérieur…

Ce que je teste, je l’éclaire

Ce que je teste, je le nomme

Ce que je teste, je l’explicite

• Je dis clairement et simplement ce que j’attends, moi développeur.

• Ce que j’attends comme comportement, c’est ce qui va œuvrer (et qui est indispensable pour) le bon fonctionnement de l’ensemble.

• Comment mon client pourrait-il être satisfait de l’ensemble, si chaque pièce ne fonctionne pas de manière irréprochable?

Tester à partir des UI?

Alors, (re)disons le

• Tester « tout » et « à la fin » : CA NE MARCHE PAS!

• Le BDD pour l’Acceptance Testing est une ARNAQUE! (Integration/Integrated Tests)

• Car les scénarios sont d’une complexité exponentielle, vous n’y arriverez pas!

• Laissez tomber Selenium! (on en reparle) http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

Pourquoi abandonner ATDD

• Si « Humble Dialog » est bien appliqué,

• tester sur l’UI revient à tester le navigateur Web ou Winform/WPF ou JFC/Swing ou ….

• (too much) code in the UI = it smells

• Integrated Tests are a scam!

Integrated Tests are a scam!

• I use the term integrated test to mean any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.

– J. B. Rainsberger

Un seul principe

KISS

• Keep it simple, stupid!

• Ce que l’on teste bien s’énonce clairement

– (ou comment ne pas boire la tasse quand on cite Boileau)

• Simple = Unique, seul

Tester c’est comprendre

• du latin « comprehensio »1, de « cum », avec, et « prehendere », prendre: action de saisir ensemble ou de prendre avec soi

Comprendre quoi?

• .. Comment ca marche (à l’intérieur)

– Ou bien

• Comment ça se comporte (de l’extérieur)

Le Test Comportementaliste

Le réserver aux IHM?

• Pourquoi n’y aurait-il que les IHM qui ont un comportement?

Qu’est ce qu’un comportement?

• Le comportement d'un être vivant et, plus généralement, de tout autre système est la partie de son activité qui se manifeste à un observateur

• http://fr.wikipedia.org/wiki/Comportement

Qui observe quoi?

On a bien dit « automatiser le test »

• L’observateur est donc un programme

…un automate

La chose observée

• est un bout de code.

• Doit être:

– Simplifiée pour mieux comprendre

– Simplifiée pour tester plus vite

– Simplifiée pour avoir un résultat plus rapidement

– Simplifiée pour rechercher les problèmes plus simplement.

• Le test lui-même doit rester simple

Simplifier = Isoler

Une chose à la fois

Single Responsibility

S.O.L.I.D. • Single responsibility principle

– the notion that an object should have only a single responsibility.

• Liskov substitution principle

– the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”

• Interface segregation principle

– the notion that “many client specific interfaces are better than one general purpose interface

Si mon code est SOLID

• Alors mes tests doivent l’être aussi

Un exemple

• Et maintenant, un peu de vrai code

Ce que m’apporte la forme BDD

T.U. classique

•ARRANGE

•ACT

•ASSERT

T.U. Behavioriste

•GIVEN

•WHEN

• THEN

Je passe au BDD

• Je passe à une description textuelle

• Exemple!

DRY

• Mes tests aussi !

• Refactoring

• Les Steps c’est beaucoup de DRY

• Exemple!

Exemple de refactoring

• Je vais gagner énormément de temps

• Fini le copier/coller… dans le code !

• Donc fini les erreurs…. sur le code (technique)

des tests!

• Exemple!

Les incontournables

• de la refactorisation :

– Dummies / Doublures

– Fake

– Mocks

– Stub

– Espions

– Helpers

Mes tests peuvent être lus

• Ce n’est plus du code, c’est du texte!!

• C’est ca qui change tout

• Je peux les échanger

• Quelqu’un de non technique pourrait les écrire

Qu'est ce que mon test raconte?

• Un scénario

• Même s’il revêt une réalité technique, le comportement devrait pouvoir être compris et approuvé par quelqu’un de logique.

• Il ne doit cibler qu’une chose à la fois (isolation)

Est ce suffisant pour faire une documentation?

• Si c’est bien raconté, oui.

• Pèsera autant qu’un lourd cahier de tests.

• J’ai gagné des semaines (voir des mois) hommes de travail de rédaction et de vérifications.

• Export automatique -> Html, Word, Pdf

Est-ce que tester "à ce point" modifie ma conception logicielle?

(design émergeant)

Oui, et de 2 façons

Penser le test en premier

• BDD = TDD

• Test First

• Anticiper plutôt que guérir

• 40 à 90% de code défectueux en moins

• 15 à 35% de temps supplémentaire au début du projet (seulement)

• Vous connaissez le cout de la correction après développement ou de la TMA…. donc... – http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Penser le comportement

Les vertus de l’abstraction

Décrire

Descriptif n’est pas Impératif

Un comportement attendu

est vérifiable à coup sur

Domain Driven Design

• C’est le meilleur moyen d’être proche du domaine métier de votre client

• Exemple (description BDD et objet métier)

Polyglot Data

• Le meilleur moyen d’être Data Storage Agnostic

• Ce n’est plus le DBA qui commande

• SQL / NoSQL ?

• La persistance est un plus, voila tout.

• Exemple: le FakeStorer dans les tests

Concevoir un comportement

• C’est penser en terme FONCTIONNELS

C’est s’interesser à l’essentiel

• On ne voit bien qu'avec le test. L'essentiel est invisible pour les yeux.

Antoine de Saint-Test

Incidences sur le code

• Penser d’abord des Interfaces qui décrivent le comportement tels que les tests ont pu les expliciter dans des scénarios mettant en évidence la valeur ajoutée du fonctionnement choisi.

• Ecrire les tests qui détaille les scénarios du comportement à observer.

• Ecrire l’implémentation.

• Vérifier.

Responsabiliser le code

• Isolation = Une seule responsabilité

• Tester c’est apprivoiser.

• « Tu deviens responsable pour toujours de ce que tu as testé »

Antoine de Saint-Test

Toujours plus fluide

• Le style change

• On devient plus « fluent »

• Le code se lit (presque) comme une phrase en langage naturel

• On se rapproche de la programmation fonctionnelle (sans changer de langage)

• Fluent API + lambda expressions = le chainon manquant?

Références

Pardon

• à Antoine de Saint-Exupéry à relire (souvent)

Questions ?