Jonathan Laurent

@johjo
47 Followers
103 Following
100 Posts

@AlpesCraft , c'est terminé.

Je souhaite remercier les organisateurs car c'est une conférence qui me fait respirer.

Quelques spécial thanks pour leurs attentions particulières durant cette journée.

- Victor Lambret
- Adeline Morel
- Marjorie Aubert
- Matthias Morard
- Anthony REY
- Colin Damon
- @cbossard
- @jpalies

Et merci à toutes les personnes que je n'ai pas mentionné. C'était un plaisir de discuter avec vous.

One of the reasons I stopped teaching guitar was that most students wanted to know "the secret", and didn't want to hear that "the secret" was regular practice.

But that really is the secret - the "one weird trick" to playing guitar better.

See also: software development.

Principe numéro 12 : les bons tests échouent.

Des tests qui passent tout le temps, en toutes circonstances, ne servent à rien.

Il est assez facile d'écrire des tests qui donnent 100% de couverture, mais qui ne vérifient rien.

Un bon test échoue, au moins une fois. Si le comportement du code change, au moins un test doit échouer.

Principe numéro 9 : un test moche est meilleur que l'absence de test.

Quand le code est moche, le test peut parfois être moche.

Personne n'aime écrire des tests moches, mais le code moche est celui qui a le plus besoin de tests.

Ne laisse pas le code moche t'empêcher d'écrire des tests, mais fais en sorte qu'il t'évite d'écrire encore plus de code moche.

Principe numéro 7 : des tests qui ne tournent pas se dégradent.

Fais tourner tes tests souvent.

Ne les laisse pas pourrir.

Réjouis toi quand ils passent.

Réjouis toi quand ils pètent.

Principe numéro 5 : le test est plus important que l'unité testée.

Certaines personnes considèrent qu'un test unitaire devrait n'avoir aucune dépendance en dehors de l'unité testée - pas de base de données, pas d'appel à distance...

La vraie réponse est : ça dépend. Si le code est fortement couplé à une dépendance externe, il vaut mieux avoir des tests qui utilisent la dépendance que pas de test "parce que ce serait pas propre".

J'ai entendu dans les couloirs de #MiXiT26 qu'il y a encore des équipes de développement, en 2026, qui n'ont pas de tests automatiques et qui ne savent pas par où commencer.

Ma référence personnelle, de l'époque où j'avais rejoint une équipe qui pratiquait "extreme programming", c'est "The Way of Testivus" par Alberto Savoia.

https://www.albertosavoia.com/uploads/1/4/0/9/14099067/thewayoftestivus.pdf

C'est une série de petites histoires humoristiques qui illustrent 12 principes liés aux tests automatiques.

Je vous propose un petit fil 🧵⤵️

J'ai oublié d'en parler ici, mais je viens de publier un nouveau billet, à propos d'une grande fierté : https://standblog.org/blog/post/2026/04/14/EROOM-Decathlon-et-la-Duck-Conf #EROOM
EROOM, Decathlon et la Duck Conf - Standblog

Il y a quelques jours, dans le cadre de la conférence Duck Conf’, organisée par mon employeur, OCTO, où Decathlon, par la voix de son global CTO, a annoncé déployé EROOM auprès de

#Grenoble Pour la nièce d'une amie, repouet souhaité de tout cœur, merci !

"Cherche chambre chez l'habitant•e (pas avec des étudiant•es) pour fille de 17 ans de juillet ou septembre jusqu'à juillet 2027 (pour l'année scolaire). Scolarisée à la Tronche, les secteurs de préférence sont La Tronche, Ile verte, centre, les quais. Si vous avez qqch à proposer merci de contacter Richard Petit : [email protected]"

Is it acceptable to use “event-sourcing-pilled”?? Cuz when I look at the supposed simplicity of using ORMs, I can’t help but think we’ve gotten so used to the hidden (and visible!) complexity that we don’t see it anymore. And then event-sourcing looks so much simpler in comparison.