dans le flux du BDD

Guillaume Saint EtienneGuillaume Saint Etienne@guillaume_agile@guillaume_agileVarian Medical SystemsVarian Medical Systems

ATTENTION

MISE AU POINT

TDD/BDD is a

design activityKerry Buckley

le test manuel est …

 

http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests

mais il faut apprendre

idée: prenez un coach ;)

goOgle est mon ennemi

• Le TOP 50 des résultats pour « BDD » (en français)– Exemples simplistes et enfantins– Pas représentatifs d’un vrai projet logiciel– Pas de vrai retour d’expérience– Articles sur BDD = ATDD (Acceptance testing /

test d’IHM)

Exception!

• Il faut rendre à César ce qui est à Pierre Irrmann• http://www.arolla.fr/blog/2012/09/bdd-et-

specflow-pour-des-tests-plus-lisibles/• « Gherkin pour écrire des tests en langage

naturel ».• « Lorsqu’on développe en BDD, les tests sont

écrits pour tester des fonctionnalités et des exemples précis de comportements. »

Parcours empiriqueParcours empirique

Ce qu’on voit en 1er

• GHERKIN / CUCUMBER–Given–When–Then

Don’t misuse it!

Ce que m’apporte la forme BDD

T.U. classique

• ARRANGE• ACT• ASSERT

T.U. Behavioriste

• GIVEN• WHEN • THEN

•Given•When•Then

•Given•When•Then

Organisation du BDD

Librairies

Features

Scenarios

Steps

Ce qui est trompeur

La puce à l’oreille

• La section « Feature » dans Gherkin– In order to– As a– I want to

…ne sert à rien!!!!

Elle n’est pas compilée et donc pas « exécutée »

Auteur: Brian Marick

Tester c’est comprendre

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

DEBUG BDD

BDD = Test Comportementaliste

Idées reçues sur le BDD• You want to do acceptance testing rather than

unit testing.• You want to use it as a communication tool

with the stake holder.• You want to do large scale tests rather than

granular tests.• You want non-technical people to write the

tests.http://gojko.net/2012/06/18/bdd-busting-the-myths/ [Gojko Adzic]http://stackoverflow.com/questions/2238176/using-fitnesse-rather-than-nunit

You want to do acceptance testing rather than unit testing.

You want to do acceptance testing rather than unit testing.

You want to do acceptance testing rather than unit testing.•TDD is excellent

You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD

You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD•BDD is first doing « unit » testing

You want to do acceptance testing rather than unit testing.•TDD is the only way to be agile•BDD is no more than TDD•BDD is first doing « unit » testing•A «non-unit » test is a scam!

– Test only one thing at a time

You want to use it as a communication tool with the stake holder.

You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself

You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself…then your team

You want to use it as a communication tool with the stake holder.First, use it as a communication with yourself…then your team…then (maybe) the stakeholder or the users.

You want to do large scale tests rather than granular tests.

You want to do large scale tests rather than granular tests.

You want to do large scale tests rather than granular tests.

http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

Why integrated tests are a scam!Why 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

You want non-technical people to write the tests.

You want non-technical people to write the tests.

You want non-technical people to write the tests.

•I wish I could …

You want non-technical people to write the tests.

•I wish I could …•Be pragmatic!

You want non-technical people to write the tests.

•I wish I could …•Be pragmatic!•Maybe in the future …

Bref, j’ai fait du BDD

• Je passe à une description textuelle• Exemple!

Bref, j’ai fait du BDD

Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1'

Et si? Je n’avais pas fait du BDD

DRY

• Mes tests aussi !• Refactoring• Les Steps Given/When/Then sont une façon

de « DRY »• Puissance (et pièges) des expressions

régulières.• Exemple…

Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1‘

Given I initialize the reader And jouvre le dossier patient '1' When je veux lire 'nais' Then I dont have error And jobtient une valeur '2/1/1973'

L’envers du décors: les Steps

Given I initialize the readerAnd jouvre le dossier patient '1'When je veux lire 'nom' Then I dont have errorAnd jobtient une valeur 'Nom 1‘

Given I initialize the reader And jouvre le dossier patient '1' When je veux lire 'nais' Then I dont have error And jobtient une valeur '2/1/1973'

Given I initialize the reader And jouvre le dossier patient 'F2' And the log system is initialized with the LogWatch configuration When I read ‘droits' as a Numeric Then I have an error And the previous log messages contains: The field 'droits' couldn't be read as a Decimal

Exemple de refactoring

• On fini par gagner énormément de temps

• Fini le copier/coller… dans le code !

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

des tests!

• Exemple!

1 Feature

1 Feature

Les Tables Specflow

Looks like Fitnesse (a bit)

Refactoring en BDD

• Nécessité de créer des Steps efficaces• Ils sont exécutables, donc il y a du code

derrière.• Même qualité du code des steps que du reste

du code.• Ré-utilisables

– Then I dont have error

Les outils incontournables

– Dummies– Fake– Mocks– Stub– Espions / Spies– Inversion de contrôle / Injection de dépendance– Helpers

– … comme dans le TDD après tout!

Fake / Substituts

• De faux objets ayant un comportement similaire à l’objet réel, mais d’une façon simplifiée.

• Il n’agit pas comme un point de contrôle, mais permet d’accélérer l’exécution des tests.

• Par exemple en remplaçant l’accès à la base de données par des données dans un fichier ou en mémoire.

Fake• « Doublure » qui fait comme l’original

ORM DB4

Test

Db 4 ObjectFile

Mocks• Une « leurre » mais pas besoin d’écrire son

code « interne »• Juste décrire ce que l’on attend de lui

Mock• Le Mock se contente de bien se « comporter ».• Simulation (Setup)• Vérification du comportement attendu

(optionnelle).

outillage contratS.U.T.

comportement attendu

Stubs

• Similaires aux MOCKs• La différence principale vient du fait qu’avec le

Stub on vérifie l’état de l’objet alors qu’avec le Mock on en vérifie le comportement (les interactions).

• http://bruno-orsier.developpez.com/mocks-arent-stubs

Refactoring steps with helpers

• Une syntaxe pour accéder aux objets (C# 3.5)• Sans:

– When je lis le champs ‘City’ dans la 1e adresse du patient en cours And je lis le champs ‘Type’ dans la 1e adresse du patient en coursAnd je lis le champs ‘Type’ dans la 2e adresse du patient en coursAnd je lis le champs ‘Type’ dans la 3e adresse du patient en cours

• Avec:

Au final, qu’est ce que je teste?

• SUT / SCT : System Under Test / Système en Cours de Test

• L’Isolation des tests est indispensable (1 problème à la fois)

• Impossible de se passer des doublures.• Un exemple avec les Spies / Espions

Single Responsibility

Chainage des vérifications

• Pas besoin de tests automatisé intégrés.• Si tous les mécanismes vu précédemment

sont en place.• Néanmoins, comment en être sûr?

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

Les CONTRATS sont la clé

Vérification automatique

• => Outil de couverture de code.

• Néanmoins difficile d’avoir 100% (erreurs de

l’outil, code inatteignable)

• Donne une très bonne mesure de

l’amélioration de la couverture par les tests.

Autres vérifications à faire

• Complétude des tests• Les « fakes » doivent être testés à leur tour.• Parcours et vérifications auto. des interfaces:

– Si une doublure (spy/mock/stub) se fait passer pour une interface, et qu’on n’en trouve pas une implémentation qui ne soit pas couverte à 100% par d’autres tests (eux même en parfaite isolation), alors c’est un échec!

– À inventer!

Patterns: HUMBLE DIALOG, VISITOR

Tests devenus inutiles: UI

Tester à partir des UI?

Test the User Interface?• « Tests »

Exploratoires (manuels)– Si Erreurs

détectées: • 5% pb de config• 10% coquilles• 10% I/O - Sys• 75 % manque de

tests

L’HEURE DU BILAN

Dans le flux

Avant le BDD

Après (dans le flux)

Ecriture du test: 5 à 30min

Steps• Écriture: 5mn à 2h

Steps• Refactoring: 1/2 à 1 journée

BILAN

La question n'est pas: combien je gagne à faire des tests? Mais,combien je perd à chaque bug en prod. #atmrs2012

Summary01/06/2010 10/10/2012 - 1:39:45 PM

8 Applications livrées (+ 6 logiciels d’installation)Tests running (2x day): 1564, Failures: 0, Inconclusive: 0, Time: 2158 seconds

STEPS:167 Given, 183 When, 209 Then 44 R. --- , 77 R.---- , 73 R. ( 26% , 42% , 35%)

Efficacité moyenne 1 groupe de steps couvre 10 scénarios

« Manual » LOC of tests/specs: 12557 / 176595 ( 14%) source monitor

Source Files: 460 (comptage par OpenCover)

Coverage: 74.5% (15% UI 10% autre non couvert)

Covered lines: 9818 (comptage par OpenCover)

Coverable lines: 13161 (comptage par OpenCover)

Total SLOC Executed in tests: 48248 (comptage par OpenCover)

BÉNÉFICES OBSERVABLES

Charge de travail effective

• Nombre de bugs déclarés en exploration et après livraison:– 1ere année: 51– 2ème année: 27

• Nombre de WorkItems (User Needs, Design Quality)– 1ere année: 98– 2ème année: 100

Les tests peuvent être lus

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

• On change de perspective (passer de l’impératif au descriptif).

• Je peux échanger avec mon équipe plus vite.• Quelqu’un de non technique pourrait-il les

comprendre? Les écrire ?

Mais on est encore très loin du langage naturel

• P.O et skateholders ne comprennent (pour l’instant) pas tout.

GAP

GAP

https://docs.google.com/viewer?url=http%3A%2F%2Fwww.scrumalliance.org%2Fsystem%2Fslides%2F118%2Foriginal%2FChristianHossa_SpecificationByExampleWithGherkin.pdf%3F1349824954

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).

MIEUX RACONTER

• Etre rigoureux à l’écriture des Steps• Se conformer au Domaine (Domain Language)• Faire du Domain Driven Design précisément

• Tests qui resteront techniques et ceux qui seront plus proches du fonctionnel

• Masquer la technique tout en permettant une bonne réutilisation des steps (!)

Est ce suffisant pour faire une documentation?

Souvent!

• Si c’est bien raconté, oui pour spécifications.• Doc Technique = OUI ! SI! YES ! JA ! DA!• Pèsera autant qu’un lourd cahier de tests.• On a gagné des semaines (voir des mois)

hommes de travail de rédaction et de vérifications.

• Export automatique des fichiers Specflow -> Html, Word, Pdf.

Décrire

Descriptif n’est pas Impératif

C’est s’intéresser à l’essentiel

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

Antoine de Saint-Test

Tests that saves faith

Références

Pardon

• à Antoine de Saint-Exupéry

à relire (souvent)

BDD dans le flux2e partie

Du Mythe à la réalité

TOUT POUR FACILITER LES TESTS

Changement de vision

Penser le comportement

Les vertus de l’abstraction

Concevoir un comportement

• C’est penser en terme FONCTIONNELS

Design émergeant

Une affaire de style

Changement de style

• the system can’t neatly be tested with automated test suites because part of the logic is dependent on often-changing visual details

• http://alistair.cockburn.us/Hexagonal+architecture

La gravité

Dépendances fatales

Modèle sans gravité

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)

Le Domaine comme modèle agnostique entre les composants

Ce que le Domaine n’est pas!

• Gestion des états => • Stateless =>

Ce que le domaine n’est pas!

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

Incidences sur le code1. Ecrire des Interfaces qui décrivent (abstraire)

ce que les tests vont spécifier dans des scénarios mettant en évidence la valeur ajoutée du comportement choisi.

2. Ecrire l’implémentation ensuite.

3. L’intégration continue vérifie tout automatiquement => non régression.

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?

En Pratique

• des DOJOS pour montrer que bien tester en 1er, et tester par le comportement induit un changement de vision dans le design du logiciel

• Une mise en œuvre des tests et du code par la simplicité, la rigueur et l’efficacité

• des exemples bientôt sur mon site http://www.dotnetguru2.org/gse/

LES TESTS D’INTEGRATION SONT ILS UTILES?

Comment on a tuer l’intégration

• Créez (ou utilisez) un mécanisme d’intégration automatique

• Testez le!• => plus besoin de tester en intégration• Ajoutez tous les tests qu’il faut pour renforcer

l’intégrité du tout.• Est-ce une bonne chose?

Du mythe…

A la réalité

UN ŒIL SUR LES ESPIONS

En pratique

S.U.TVérification de comportement en parfaite isolation

SONT-ILS BIEN TESTES?

Les pièges à éviter

• Dire « comment » au lieu de « quoi »• Ne pas laisser transparaitre le « software

design »• Le « software design » devrait se fondre dans

les spécifications et devenir naturel• Ne pas se laisser enfermer dans les détails • Ne pas tout tester en même temps (bis

répetita)

Pièges (Suite)• Garder les tests parlants… (pour qui?)• Ne pas sur-spécifier (YAGNI sur les tests)• La partie setup/Given devrait rester simple• Utiliser un « ubiquitous languange »• Ne retardez pas l’usage des doublures,

injection de dépendance et autres assistants• Ne pas sous-estimez votre code « assistant »

(testez les aussi bien)

• Introduire une part de travail manuel

(suite)

• Se baser sur des données pré-existantes(!!)• Ne pas être certain que chaque test soit

idempotent.• Perdre du sens par soucis de concision

(masquer la réaliter au lieu de la simplifier)

• L’endettement (on fini toujours par payer, et les taux augmentent avec le temps)

Trucs• Commencer petit• Progresser à son rythme• Refactorer régulièrement• Le temps est votre allié

DRY! KISS! YAGNI! SOLID!

Tests that saves faith