iiinova — where your digital self keeps evolving

Charles Desneuf @selrahcd.bsky.social · 10/07/2026

This is not my most useful skill but I’m apparently able to tell the first 50 decimals of pi from memory (for now, and quite slowly, but still)

A screen showing that 50 decimals of Pi are correct.

010

Charles Desneuf @selrahcd.bsky.social · 11/06/2026

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.

000

Charles Desneuf @selrahcd.bsky.social · 11/06/2026

Keep a glossary, evolve it, watch the drift.

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,

100

Charles Desneuf @selrahcd.bsky.social · 11/06/2026

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.

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.

110

Charles Desneuf @selrahcd.bsky.social · 11/06/2026

“When the words split, the boundary has already moved. The code is just the last to find out.” Omphile Matheolane #DDDEU

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.

131

Charles Desneuf @selrahcd.bsky.social · 01/05/2026

Super, mais n’en abusons pas !

000

Charles Desneuf @selrahcd.bsky.social · 30/10/2025

Hello les internets, des ces phrases, laquelle vous donne envie d’en savoir plus:

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é

211

Charles Desneuf @selrahcd.bsky.social · 11/08/2025

- The switcher has a "switchToDatabase" method that sets the instance property to the database implementation. Here is an example of a switcher:

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

100

Charles Desneuf @selrahcd.bsky.social · 08/08/2025

Gotta love your ORM

$A great ORM query await global.prisma.ponyVictories.findUnique( { where: { riderId_ponyId_competitionId: { riderId, ponyId, competitionId, }, } })$

010

Charles Desneuf @selrahcd.bsky.social · 02/04/2025

I don’t know if that is the real story but I like that instead of trying to do post update someone came up with idea to allow for copying a post. Just delete, create a new one, paste, edit, send. That’s a nice agile trick to solve user problems.

000

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

TIL, from Modern C++ programming with TDD

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.

000

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Retrouve d'autres idées pour améliorer tes tests dans mon guide gratuit formation.charlesdesneuf.com/guide-gratui... ou dans ma formation en vidéo, dans laquelle on voit ensemble comment rendre des tests pas top vachement mieux ! formation.charlesdesneuf.com/ameliorez-vo...

000

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Il n'est pas possible de suivre le pattern AAA pour les tests d'exception en raison du fonctionnement des frameworks. Ils ont besoin de savoir en avance quelle exception attendre, pour ne pas la traiter comme une erreur.

## 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>

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Si vous voyez une attente d'exception en fin de test, c'est qu'il y a quelque chose qui cloche avec ce test. Normalement ce test devrait être en échec. S'il ne l'est pas, c'est trèèèès louche.

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

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Comme on vient de le voir, le pattern Arrange-Act-Assert ne fonctionne pas pour les tests d'exception car on doit prévenir le framework de test avant que l'exception ne soit lancée. Pour un rappel sur AAA: bsky.app/profile/selr...

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

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Que doit-on faire si l'exception attendue n'arrive jamais ? On veut que notre test échoue. Il faut donc rajouter de la logique pour cela.

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

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

C'est chouette, mais il reste quand même un problème à régler. Tu vois lequel ?

## 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 😅

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Le framework a désormais toutes les infos dont il a besoin pour s'assurer que l'exception lancée est celle que l'on attendait.

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

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Pour éviter ça, il faut trouver un moyen de mettre le framework au courant que l'on s'attend à voir cette exception arriver.

## 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()
}
```

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Quand le système sous test lance une exception, le framework l'attrape et la traite comme une erreur. Tout l'inverse de ce que l'on veut en fait...

## 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 ! 🤦

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Petit rappel de la dernière fois sur notre framework de test. Pour tout se remettre en mémoire: bsky.app/profile/selr...

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

100

Charles Desneuf @selrahcd.bsky.social · 01/04/2025

Comment font les frameworks de test pour nous permettre de vérifier qu'une exception est lancée par le système sous test ? On voit ça ensemble maintenant ! 🧵

# 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>

100

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

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

000

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

En gros, la base d'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 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.

100

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

La solution, c'est de mettre un try/catch dans la boucle, et de récupérer chacune des erreurs pour pouvoir les afficher plus tard.

## 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;
}
}
```

100

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

Le problème c'est que les exceptions cassent la boucle. Le premier test qui échoue empèche les autres tests de s'exécuter. C'est vite pénible de devoir relancer les tests pour n'avoir les informations d'échec que pour un test. Ça nous prive d'info qui pourraient nous aider à corriger le problème.

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

100

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

Pour faire des vérifications, on utilise des assertions dans les tests. Les assertions jettent une exception quand le test échoue, ce qui permet de remonter l'erreur. Ça c'est la base de la base de la base, mais c'est pas parfait du tout...

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

On a la base de notre framework de test 💪

Mais il est loin d'être parfait...

110

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

Un framework de test c'est grosso-modo une boucle qui exécute des fonctions les unes à la suite des autres. Chaque fonction représente un test.

## 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();
}
```

100

Charles Desneuf @selrahcd.bsky.social · 25/03/2025

Créer son propre framework de test permet de mieux comprendre leur fonctionnement, ce qui aide à écrire de meilleurs tests. Aujourd'hui on fait la base de la base. La prochaine fois on continuera à construire là dessus. C'est parti 🧵

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

L'idée de ce carousel, et des suivants (abonne-toi 😉), n'est pas de créer un vrai framework de test, mais d'avoir une compréhension basique de leur fonctionnement.

Cela aide à mieux comprendre certaines "règles" d'écriture des tests.

110

Charles Desneuf @selrahcd.bsky.social · 21/03/2025

Is anyone interested in 500 stickers « Bar de merde » ?

A pack of 500 stickers « Bar de merde - I told you so »

000

Charles Desneuf @selrahcd.bsky.social · 18/03/2025

En faisant attention à différencier la règle de l'exemple cela vous permet de réduire le nombre de tests à maintenir et d'avoir des tests avec des noms plus parlants, qui peuvent servir de documentation. Cool nan ?

## À 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!

100

Charles Desneuf @selrahcd.bsky.social · 18/03/2025

On peut aussi utiliser plusieurs exemples pour illustrer une même règle grâce aux tests paramétrés. Ça permet d'avoir moins de tests à maintenir.

$## 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()); } } ```$

110

Charles Desneuf @selrahcd.bsky.social · 18/03/2025

C'est aussi une super règle à suivre pour réussir à créer de la documentation utile à partir de tes tests !

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

100

Charles Desneuf @selrahcd.bsky.social · 18/03/2025

C'est important pour le nommage des tests. Il est préférable d'éviter de nommer nos tests en fonction de l'exemple utilisé.

## 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 !

100