Charles Desneuf
LightNews LightNews
selrahcd.bsky.social
Charles Desneuf
@selrahcd.bsky.social
210 followers 510 following 440 posts
Agile Tech coach
Expect to hear about testing, archi, DDD, and maybe music.
Posts Replies Media Videos
selrahcd.bsky.social
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é
October 30, 2025 at 8:16 AM
selrahcd.bsky.social
- 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) } }
August 11, 2025 at 7:48 AM
selrahcd.bsky.social
Gotta love your ORM
A great ORM query await global.prisma.ponyVictories.findUnique( { where: { riderId_ponyId_competitionId: { riderId, ponyId, competitionId, }, } })
August 8, 2025 at 8:42 AM
selrahcd.bsky.social
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.
April 2, 2025 at 6:57 PM
selrahcd.bsky.social
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.
April 1, 2025 at 3:30 PM
selrahcd.bsky.social
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...
April 1, 2025 at 7:01 AM
selrahcd.bsky.social
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>
April 1, 2025 at 7:01 AM
selrahcd.bsky.social
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.
April 1, 2025 at 7:01 AM
selrahcd.bsky.social
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.
April 1, 2025 at 7:01 AM
selrahcd.bsky.social
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.
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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 😅
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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.
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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() } ```
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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 ! 🤦
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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.
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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>
April 1, 2025 at 7:00 AM
selrahcd.bsky.social
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...
## 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.
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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.
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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; } } ```
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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.
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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...
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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(); } ```
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
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.
March 25, 2025 at 8:00 AM
selrahcd.bsky.social
Is anyone interested in 500 stickers « Bar de merde » ?
A pack of 500 stickers « Bar de merde - I told you so »
March 21, 2025 at 7:05 PM
selrahcd.bsky.social
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!
March 18, 2025 at 8:00 AM