Charles Desneuf

@selrahcd.bsky.social

250 Followers 523 Following

Agile Tech coach Expect to hear about testing, archi, DDD, and maybe music.

A screen showing that 50 decimals of Pi are correct.
"The Abilene Paradox' describes a situation where a group collectively decides on a course of action that is counter to the preferences of most or all of the individuals in the group. It's based on a story of a family who collectively decides to take a long, uncomfortable trip to Abilenedespite none of them individually wanting to go-because each mistakenly believes the others want to go. The paradox occurs when members incorrectly believe their own preferences are contrary to the group's and, therefore, do not raise objections. This results in a situation where no one is happy with the outcomes, even though everyone believes it's what the group wants. In collaborative environments, a lack of clarity and alignment can take you places nobody wants to go." (Steve Pereira and Andrew Davis, Flow Engineering)
"The real medium of any design then is *decisions*. The more decisions are already made, the more the direction is set, and the fewer “degrees of freedom” remain. As the degrees of decision freedom are “spent”, there is less wiggle room for agility. The opposite of Agile isn’t “slow”—it’s “path dependent”. To raise the agility ceiling in the organization you need to bake options into planning to preserve degrees of freedom." (Charles Lambdin, Design and Agile’s Muddied Waters)
Clarity isn't lost in a redesign. It's lost in a thousand small, reasonable decisions. And it's kept the same way. One deliberate decision at a time, mostly about words.
Watch the language Make the glossary a living artifact that sits next to the code, not a wiki page that died in 2023. Keep the glossary in the repo A term file per context, reviewed in the same PR as the code. If the word changes, the diff shows it. Define terms per context, not globally "Payment" is allowed to mean different things in different boxes. The glossary records that on purpose. Treat a new qualifier as a signal The first time someone writes billing Customer, ask whether a new term, or a new boundary,
Read the intent behind the word A shared word is not proof of a shared meaning. What decides whether two uses belong together is intent, what each person is actually trying to do. Keep Same word, same intent One context. The shared term is doing its job. Leave it alone. Unify Split Same word, different intent A boundary is forming under a single word. This is the split worth naming. Different words, same intent Most likely synonyms. Unify the language before they drift apart.
A bounded context is an agreement, not a structure, The boundary live in the language. When the words split, the boundary has already moved. The code is just the last to find out. So the health of a boundary is the heath of its language, long before it is the shape of its code.
"Once managers figure out what they mean and why it matters, the issue in question starts to look a lot more measurable." (Douglas W. Hubbard, How to Measure Anything)
"Excessive complexity is nature’s punishment for organizations that are unable to make decisions." (Gregor Hohpe, Gregor’s Law)
Un réveil qui indique « FRI MAY01 »
"Encapsulation is important, but the reason why it is important is more important. Encapsulation helps us reason about our code. In well-encapsulated code, there are fewer paths to follow as you try to understand it. Encapsulation isn’t an end in itself; it is a tool for understanding. — Michael Feathers, [Working Effectively with Legacy Code](https://books.google.co.uk/books/about/Working_Effectively_with_Legacy_Code.html?id=CQlRAAAAMAAJ)" (Kevlin Henney, Restrict Mutability of State)
"An often overlooked point is that WIP limits should not **only** be an upper limit, but an optimum. > It’s one thing that the overwhelming majority of flow practitioners get wrong and that is thinking that a wip limit is an upper limit. A wip limit should represent a system’s capacity which means being under a wip limit is just as bad as being over the limit. — Dan Vacanti via ProKanban.org Slack Channel Let’s assume we have a system-wide WIP limit of 5 items. That means that 5 would be the optimum. With 5 items, the system performs the most efficient and effective. We should not have 6 or more items in progress. But also we should not have less than 5 items, as this would mean we’re “wasting” capacity of this system." (Benjamin Huser-Berta, Limit Work in Progress Without Work in Progress Limits)
"As a company, you can’t rely on good intentions—e.g., “try harder” or “next time, remember to…“—as a way to solve problems. Most people already have good intentions: they are already trying hard and doing their best to remember things, but intent and personal desire just aren’t enough. To really fix problems, you need to put in place mechanisms: that is, you need to create or modify the systems and processes within which people work." (https://www.facebook.com/brikis98, Review: Working Backwards by Colin Bryar and Bill Carr)
"The causality of neglect is hard to see because it is an absence of a thing — care, attention, remediation, work — rather than a thing that is easily observed. Inaction lacks the visibility of action. Searching for improvement becomes more a question of “What are we not doing?” than “What are we doing wrong?”" (Kevlin Henney, You Will Never Know Enough)
"In Skinner’s work, here’s where things get interesting. If the pigeons received the reward every time, they moderated their behaviour – they pecked when they wanted to eat. But, if the reward was made ***variable, and unpredictable***, they went pretty crazy pecking incessantly. They behaved like addicts. This also feels like what’s happening in business. Your organization releases something that does well. It makes your company lots of money. We’re not sure exactly why, but that doesn’t matter. Now we know how it works. > ***Release something then get an unpredictable reward. So we do just that. And we get addicted to releasing more things faster. Just like Skinner’s pigeons.***" (jpattonassociates.com, Underpants Gnomes, Outcomes, and Intermittent Reinforcement)
NPS survey asking “Recommanderiez-vous Europcar?” 5-6 in red 7-8 in yellow 9-10 in green Nothing from 1 to 4 🤷‍♂️
1. Écris des tests que tu ne rêves pas de jeter 2. Sois le dev qui écrit des tests de qualité 3. Deviens un dev qui écrit des tests de qualité 4. Améliore tes tests automatisés en 3 mois 5. Des tests de qualité en 3 mois pour les devs 6. Des tests fiables, rapides, lisibles, et maintenables en 3 mois 7. Des tests automatisés sans cauchemars 8. Écris enfin des tests de qualité 9. Réduis de 50% le temps de maintenance de tes tests en 90 jours 10. Construits une suite de test stable et rapide en 8 semaines 11. Deviens un tech lead qui sait construire une stratégie de test efficace 12. Deviens le développeur expert en test de ton équipe 13. Livre des features en confiance grâce à ta suite de test 14. N’aie plus peur de livrer des features grâce à des tests de qualité
Here is the implementation. /*This class is not meant to stay. This is something temporary to allow for switching the implementation test by test */ export class TestSwitcherPonyCareRepository implements PonyCareRepository { private instance: PonyCareRepository constructor( private mockPrismaPonyCareRepository: PrismaPonyCareRepository, private realPrismaPonyCareRepository: PrismaPonyCareRepository, ) { this.instance = mockPrismaPonyCareRepository } switchToRealDatabase() { this.instance = this.realPrismaPonyCareRepository } async fetchCareSchedules( stableId: StableId, ponyId: PonyId, ): Promise<PonyCareSchedule[]> { return this.instance.fetchCareSchedules(stableId, ponyId) } async saveCareUpdates( careScheduleToSave: PonyCareScheduleToSave, ): Promise<void> { return this.instance.saveCareUpdates(careScheduleToSave) } }
A great ORM query await global.prisma.ponyVictories.findUnique( { where: { riderId_ponyId_competitionId: { riderId, ponyId, competitionId, }, } })
Hamcrest assertions​ were introduced into unit testing tools several years ago in an attempt to improve the expressiveness of tests, the flexibility of creating complex assertions, and the information supplied by failure messages. Hamcrest uses ​ matchers​ (“Hamcrest” is an anagram of “matchers”) to declare comparisons against actual results. Matchers can be combined to build complex yet easily understood comparison expressions. You can also create custom matchers.
## Récap Puisque les frameworks de tests se basent sur les exceptions pour indiquer une erreur, cela les forces à mettre en place un `try/catch`. Pour être capable de différencier une exception attendue d'une exception inattendue, il faut l'indiquer au framework de test avant qu'elle soit déclenchée. C'est pour cela que suivre le pattern Arrange-Act-Assert n'est pas possible quand on veut tester qu'une exception est lancé. <span class="small">On se retrouve la semaine prochaine pour continuer sur ce sujet 👋</span>
## Méfiez-vous des expects exceptions de fin de tests Si vous voyez l'attente d'exception **après** l'action : ```php $choux->mélangerAvec($carottes); $this->expectException(OnNePeutPasMélangerDuChouxAvecDesCarottes::class); // Puis l'attente - Trop tard! ``` Ce test ne vérifiera jamais correctement le lancement de l'exception ! Heureusement, le framework de test va vous signaler le problème, puisqu'il va attraper l'exception.
## Pas de AAA Le pattern Arrange-Act-Assert ne fonctionne pas pour les tests d'exceptions car le framework doit savoir **avant** l'action qu'une exception est attendue.
## L'exception attendue n'arrive jamais C'est vrai ça. Pour le moment, si l'exception n'est jamais lancée, le test n'est pas marqué comme en erreur. ```diff foreach(tests as test) { expectedException = null try { test() } catch(exception) { if(exception != expectedException) { failedTests[] = exception } + continue } + if(expectedException) { + failedTests[] = + NeverReceivedExpectedException(expectedException) + } } ``` Si on a géré une exception, on passe au test d'après avec un `continue`. En revanche, si on attendait une exception, et qu'on ne l'a pas eu, on rajoute une erreur.
## Ok mais.. Ça fonctionne bien, mais c'est pas encore parfait. Il nous reste encore un problème à régler. Et à mesure qu'on règle des minis problèmes, on comprend pourquoi se faire son propre framework est sans doute pas une si bonne idée que ça 😅
## Comparer les exceptions Le framework peut maintenant vérifier si l'exception attrapée correspond à celle attendue : ```diff failedTests = []; foreach(tests as name => test) { + expectedException = null try { test(); } catch (exception) { + if(exception != expectedException) { + failedTests[name] = exception + } } } ``` L'`expectedException` est réinitialisée avant chaque test. Sans ça, si un autre test jette `MonExceptionMetier` alors qu'il ne le devrait pas, il serait quand même vert.
## Le framework doit être au courant Il faut signaler au framework qu'on s'attend à une exception **avant** qu'elle ne soit lancée: ```js maFonction() { throws MonExceptionMetier } test4() { // On indique l'exception attendue d'abord expectedException = MonExceptionMetier // Toujours le même code maFonction() } ```
## Le problème avec les tests d'exceptions Quand on veut tester qu'une exception est lancée : ```js maFonction() { throws MonExceptionMetier } test4() { // Du code qui lance une exception maFonction() } ``` Le framework va capturer cette exception et la considérer comme un échec du test, même si c'est le comportement attendu ! 🤦
## Les bases d'un framework de test On repart d'où on est parti la dernière fois, voici notre framework de test basique : ```js failedTests = []; foreach(tests as name => test) { try { test(); } catch (exception) { failedTests[name] = e; } } if(failedTests == []) { print "Tous les tests ont réussi!"; } else { print "Ces tests ont échoué: "; foreach(failedTests as failedTest) { print failedTest; } } ``` Mais si, souviens-toi, les assertions communiquent les erreurs via des exceptions.
# Créer un framework de test - Exception ? Comment les frameworks de tests font-ils pour s'assurer qu'une exception est lancée ? <span class="small">Je te rajoute le lien vers l'épisode précédent pas loin ⬇️</span>
## Tu veux améliorer tes tests ? Si tu rencontres des problèmes de maintenance avec tes tests, s'ils ne sont pas assez lisibles, s'ils cassent pour de mauvaises raisons, je peux t'aider. Accède à ma formation vidéo ou jette un coup d'oeil à mon guide gratuit pour améliorer la lisibilité des tests.
## La base Un framework de test c'est: - une boucle - des exceptions - un try/catch - et de quoi afficher le résultat La prochaine fois, on discutera de l'impossibilité de suivre le pattern Arrange - Act - Assert quand on s'assure qu'une exception est lancée par le système sous test.
## La solution: try/catch Les frameworks de test encapsulent chaque test dans la boucle dans un bloc try/catch: ```js failedTests = []; foreach(tests as name => test) { try { test(); } catch (Exception e) { failedTests[name] = e; } } if(failedTests == []) { print "Tous les tests ont réussi!"; } else { print "Ces tests ont échoué: "; foreach(failedTests as failedTest) { print failedTest; } } ```
## Le problème de cette approche simple Avec seulement une boucle et des exceptions, le premier test qui échoue stoppe l'exécution : ```js tests =[ 'test1': () => { assertEquals("Hello", "Hola") } 'test2': () => { /* votre code de test */ } 'test3': () => { /* votre code de test */ } ]; foreach(tests as test) { test(); } ``` Ici, `test2` et `test3` ne seront jamais executés car `test1` échoue. Ce n'est pas idéal - nous voulons exécuter tous nos tests et voir tous les échecs en une seule fois.
## Et des assertions qui lancent des exceptions Les assertions sont le moyen par lequel les tests valident le comportement du code. Ce sont des fonctions qui jettent des exceptions si les valeurs passées ne correspondent pas à ce que l'on attend. ```php assertEquals = ($attendu, $réel) => { if($attendu != $réel) { throw AssertionException( "$attendu et $réel ne sont pas égaux" ) } } ``` Si aucune exception n'est lancée, le test réussit.
## Une boucle sur des fonctions... La base d'un framework de test est une simple boucle qui exécute des fonctions : ```js tests =[ 'test1': () => { /* votre code de test */ } 'test2': () => { /* votre code de test */ } 'test3': () => { /* votre code de test */ } ]; foreach(tests as test) { test(); } ```
# Créer un framework de test - part 1 Avoir un modèle mental du fonctionnement des frameworks de test aide à écrire de meilleurs tests automatisés.
A pack of 500 stickers « Bar de merde - I told you so »
## À retenir sur l'Example-Based Testing - Vos méthodes de test contiennent des exemples concrets - Vos noms de test doivent exprimer des règles métier générales - Cette différence permet de mieux structurer vos tests - La paramétrisation est votre alliée pour tester une règle avec plusieurs exemples - Des tests bien nommés et bien organisés servent de documentation vivante Gardez en tête que chaque exemple dans votre code est là pour illustrer une règle métier plus large!
## Plusieurs exemples pour une règle Ça permet aussi de diminuer le nombre de tests à maintenir. On peut utiliser plusieurs exemples pour illustrer une même règle grâce à la paramétrisation. ```php final class BurritoTest extends TestCase { #[TestWith(['boeuf haché', 'salade', 'fromage', 'avocat'])] #[TestWith(['thon', 'salade', 'fromage', 'avocat'])] public function un_burrito_avec_viande_ou_poisson_est_non_végétarien(array $ingrédients) { $burrito = new Burrito($ingrédients); $this->assertFalse($expected, $burrito->estVégétarien()); } } ```
## C'est mieux pour la documentation Si tu vois tes tests comme de la documentation, as-tu envie de lire un test pour chaque burrito végétarien ou non du monde et essayer de deviner pourquoi "thon, steak, riz, moules" n'est pas végétarien ?* Probablement pas, tu veux connaitre la règle métier : si y'a de la viande ou du poisson, c'est pas végé. Bon sang mais c'est bien sûr 🤦! *En plus d'être certainement dégueulasse.
## C'est important pour le nommage des tests Dans la grande majorité des cas, on ne veut pas que les noms de tests fassent mention d'un exemple particulier, on veut qu'ils expriment une règle plus générale. On ne veut pas un test qui s'appelle `a donne b`, mais plutôt `lettreSuivante retourne la prochaine lettre de l'alphabet`. Mais c'est pas tout !
## La différence est cruciale **Règle métier (abstraite):** - "Un burrito avec de la viande ou du poisson n'est pas végétarien" **Exemples (concrets):** - Un burrito avec du bœuf haché n'est pas végétarien - Un burrito avec du thon n'est pas végétarien La règle est générale, les exemples sont spécifiques.
## Le nom du test exprime une règle métier ```php /** * @test */ public function un_burrito_sans_viande_et_sans_poisson_est_végétarien(): void { // ... } ``` Le nom du test exprime une règle métier générale: "Un burrito sans viande et sans poisson est végétarien" Ce n'est pas juste "Ce burrito avec de la salade, du fromage, de l'avocat et un œuf est végétarien"
## Le corps du test est un exemple concret ```php /** * @test */ public function un_burrito_sans_viande_et_sans_poisson_est_végétarien(): void { $burrito = new Burrito(['salade', 'fromage', 'avocat', 'oeuf']); $this->assertTrue($burrito->estVégétarien()); } ``` Le corps du test est un exemple spécifique qui illustre notre règle métier. Ici, on utilise le Burrito qui contient de la salade, du fromage, de l'avocat et un œuf comme exemple de burrito végétarien. On pourrait trouver plein d'autres exemples.
## Qu'est-ce que l'Example-Based Testing? L'Example-Based Testing est une approche où vous validez le comportement d'un système en fournissant des exemples concrets d'entrées et de sorties attendues. C'est l'approche la plus courante pour les tests automatisés et la plus intuitive pour les développeurs. Il y a de grandes chances que ce soit ce que tu fasses.
# L'Example-Based Testing Comment faire en sorte que vos tests concrets illustrent des règles métier
## Les leçons à retenir 1. Ne créez pas de doublure des librairies externes 2. Laissez vous guider par votre langage métier 3. Testez l'intégration avec de vrais composants 4. Ne doublez uniquement que ce que vous possédez Ainsi vous êtes mieux protégés des changements externes.
## La révélation Lors de la mise à jour du Kulinarisk : - Le test avec la doublure passe (il ne vérifie que le nom de la méthode) - Le test d'intégration échoue ! Il détecte que le four ne transforme plus le pain en pain grillé. Sans ce test d'intégration, nous n'aurions découvert le problème qu'en production.
## Ok, mais si le Kulinarisk tombe en panne ? Il n'y a pas de mystère, il faut un test du `FourDeLaCuisine` avec un vrai `Kulinarisk`. Pour gagner du temps, on peut tester sur une cuisson plus rapide que les poivrons, comme du pain. ```php public function intégration_le_four_fonctionne(): void { $four = new FourDeLaCuisine(new AKEI\Kulinarisk()); $this->assertEquals( new PainGrillé(), $four->cuire(new Pain(), 2) ); } ``` Un peu d'alerting aide aussi un peu ici 😉
## Des tests qui parlent le langage du domaine On peut maintenant utiliser l'interface `Four` dans notre test : ```php public function prépare_des_poivrons_fondants_avec_un_four(): void { $poivron = new Poivron(); $four = $this->createMock(Four::class); $four->method('cuire') ->with($poivron, 25) ->willReturn(new PoivronFondant()); $cuisinier = new Cuisiner($four); $platPréparé = $cuisinier->prépareUnPoivronFondant($poivron); $this->assertEquals(new PoivronFondant(), $platPréparé); } ``` Le test ne sait même pas qu'un Kulinarisk existe et est exprimé dans le langage du domaine !
## Une implémentation Une interface c'est bien, mais il nous faut quand même un véritable four. Notre four de la cuisine est un Kulinarisk ```php class FourDeLaCuisine implements Four { public function __construct( private readonly AKEI\Kulinarisk $kulinarisk ) {} public function cuire($plat, $duréeEnMinute) { return $this->kulinarisk->bake($plat, $duréeEnMinute); } } ``` Le four de la cuisine délègue le travail au Kulinarisk et fait la traduction.
## Comment faire mieux ? Laissons nous guider par le langage. On l'a vu, on a du vocabulaire étranger à notre domaine dans notre code. Corrigeons cela avec une interface `Four` : ```php interface Four { public function cuire($plat, $duréeEnMinute); } ``` Cette interface définit le langage de notre domaine.
## Deuxième problème : la prod est cassée En prod, plus rien ne fonctionne ! La nouvelle version de `bake` ne fonctionne pas comme `laga` : ```php public function bake($dish, int $duration) { $durationInSeconds = $duration * 60; sleep($durationInSeconds); return $dish; // Retourne le plat sans le transformer ! } ``` AKEI a introduit un bug dans la nouvelle version du Kulinarisk 🤦 Notre mock nous a caché ce changement de comportement !
## Premier problème : la mise à jour AKEI sort une nouvelle version : ils renomment `laga` en `bake`. Notre test avec mock échoue car il cherche à configurer une méthode `laga` qui n'existe plus. On modifie notre mock sans trop réfléchir : ```php $kulinarisk->method('bake')->with($poivron, 25) ->willReturn(new PoivronFondant()); ``` Et hop, le test repasse. Tout va bien ?
## Le langage nous parle Notre code est en français : - Cuisinier - prépareUnPoivronFondant - PoivronFondant Mais le Kulinarisk utilise des méthodes en suédois : - laga - maträtt - varaktighet C'est un signe que nous utilisons directement une librairie externe sans l'adapter à notre domaine.