Comme tous les ans, se tiendra la soirée de l’Agile Testing Night #3 au siège de la Société Générale. Le fil rouge principal de cette soirée était le testing en mode Agile et plus particulièrement le TDD.

J’ai assisté au début à la keynote TDD is dead, long live to TCR de Xavier DETANT , CTO Zenika, suivie d’une table ronde Le BDD remplacerait-il le TDD ? animée par Bruno BOUCARD & Thomas PIERRAIN, les cofondateurs de la société 42skillz.

Keynote : Le TDD est mort, longue vie au TCR - Xavier DETANT (Zenika)

Le TCR introduit un nouveau concept Test && commit || Revert, qui est un peu différent du TDD, et consiste au workflow suivant :

• Ecrire un TU rouge
• Ecrire le minimum du code pour le faire passer
• Si le test passe alors commit, sinon revert

Cette pratique risque de créer beaucoup de frustration pour les développeurs, vu qu’ils vont devoir supprimer le nouveau code suite à un TU rouge ! La pratique du TCR pousse à faire des changement tellement petit pour limiter les problèmes de merges ==> Workflow limbo

Pour les actions importantes / urgente; voir la matrice de Eisenhower

I hated the idea, but, I have to try

Plus de détails sur :

• blog de Zenika.
• Article de Kent Beck

Eisenhower Matrix

The Eisenhower Matrix, also referred to as Urgent-Important Matrix, helps you decide on and prioritize tasks by urgency and importance, sorting out less urgent and important tasks which you should either delegate or not do at all. (See Eisenhower Matrix)

	Urgent	Less Urgent
Important	Do First : First focus on important tasks to be done the same day.	Schedule : Important, but not-so-urgent stuff should be scheduled.
Less Important	Delegate : What’s urgent, but less important, delegate to others.	Don’t Do : What’s neither urgent nor important, don’t do at all.

Part 2 : Le. BDD remplacerait-il le TDD ? - Bruno BOUCARD / Thomas PIERRAIN @42skills

BDD

• Découverte
• Example mapping
• Atelier 3 amigos
• Formulation
• Gherkin

L’intérêt du BDD est d’avoir des scénarios utiles exprimés avec les mots du métier.

L’automatisation de BDD est Couteuse. Parmi les outils utilisés :

• Cucumber
• SpecFlow

Parmi les problématiques remontées : Lors de la partie Gherkin, on passe du temps a convertir le besoin du métier en ligne Gherkin, au lieu de se concentrer sur la compréhension / échange sur les besoins métiers. Ainsi, on passe plus de temps sur l’accessoire que sur l’essentiel.

Il est donc conseillé d’utiliser l’Example Mapping parce que le format est plus simple et moins contraignant que Gherkin. L’exemple mapping consiste à 4 type de cartes :

• Carte Story
• Carte Critère d’acceptation (Acceptance criteria)
• Carte exemple
• carte Questions

Cette pratique permet des interactions plus efficaces, tout en restant bien focus sur la story.

Pour plus de détails, voir cet article.

Event Storming

Atelier pour définir les éléments qui ont de la valeurs au métier.

Cucumber

C’est un outil open source qui permet d’avoir une documentation vivante du code, à travers des tests des spécifications métier. Ainsi, le business peut suivre l’évolution de production du code.

ATDD

On a également parlé du ATDD pout Acceptance Test Driven Development. Le principe est d’écrire un test de critère d’acceptance qui est en échec, ensuite itérer plusieurs boucle de TDD pour le passer en vert.

GAUGE

Gauge tests are in Markdown which makes writing and maintaining tests easier. Reuse specifications and robust refactoring to reduce duplication. Less code and readable specifications means less time spent on maintaining the test suite.

Types de tests

On peut différence les écoles :

• Outside-In
• Inside-Out

London school : Outside-in & Mock

Outside-in TDD

Le système est considéré comme une boite noire. Le développeur écrit un test qui échoue sur une fonctionnalité (basée sur des critères d’acceptance), et ensuite écris du code pour faire passer le test en vert.

Voir cet article qui explique le principe.

Mock

• Répond la question & peut être questionné si il a utilisé pour les tests
• Enregistrer ce qui se passe
• Vérifier si le mock a été modifié

Stub

Programmé pour répondre a une question.

Chicago School : Inside Out (Classical Approach)

Les problèmes qu’on pourrait avoir avec l’approche Inside out est le risque de se perdre dans le chemin, quand le système va grossir. L’avantage de l’outsider in est d’avoir un point de cadrage sur le résultat attendu.

Conseils

• il faut toujours se poser la question suivante lors de l’écriture des tests ou du refactoring : Est ce que j’ai utilisé le langage du métier dans mon code ? Ceci permet d’avoir un code qui répond au mieux aux exigences du métier, qui est plus maintenbale et compréhensible.
• Il faut tester les comportement, et non pas l’implémentation.

Katas

• Kata bank
• Kata Diamond : Kata ou on revisite a chaque fois les règles métiers :