.Net Core Testing: pushing the limits en

Let's discover and unleash the power of automated testing using xUnit with related technologies such as Test Containers and Benchmark Testing.
From the basics to more advanced topics, step by step, we gonna
dive in the thrilling world of asynchronicity, and how to handle its subtleties when it comes under test.
Live coding, real world enterprise oriented C# examples.

What is a testable architecture? en fr

Software architecture has so many facets, so many variations.
A true matter of style, a patchwork of proposals, influenced by fashion trends sometimes.
But how testable is yours?
And what is a good test, in your humble opinion?
What are the genuine characteristics of effective tests?
What are your expectations when it comes to bring your systems under tests?
Let's analyze those crucial, almost philosophical questions (I doubt, therefore I test? Or the opposite ?).
Integration(s), connascence and testability are crucial to question when time comes for architectural choices.

Mob atelier TDD et DDD, vers une architecture Hexagonale fr en

En 3 ou 4h, nous allons apprendre à mettre en oeuvre le TDD de manière concrète, avec une approche DDD pour un cas métier, et des adapters vers des services externes. Un cas simple qui fait se poser beaucoup de question. Préparez vous à être surpris.

Comprendre les tests unitaires et le besoin de doublures dans un début d’architecture hexagonale; clarifier ce que l’on appele doublure de tests.

TDDD : Hexagonal testing with Doubles fr en

You're asking yourself: how to practically isolate my domain code from moving parts like databases or external systems, APIs... in the simplest way either. How can I do that without integration testing. Are Unit Test sufficient? Can I apply TDD literally?
I've heard about mock as a perfect solution to test my dependencies.
Well, we need to talk. Better than that: we need to code!
Let's work on a very concrete and representative example. And let's mob it!

Format: 3/4h ( live coding/workshop) ; fish bowl MOB programing
Isolate domain rules and invariants
Add external system and test then
Learn about test doubles : stubs, spy, fake, mocks
When and how to use it? How to avoid mocks.

We will work on Concrete examples:
- ask time / generate random values (like UUIDs)
- send a mail / print an invoice
- access to an external resource (like a file)
- invoke a read/write repository
- summon an API
Showing what’s legitimate and what’s beyond reason

Profession Développeur: prisme de la société ou singularité? en

Assurément, mon titre aurait dû être "Profession développeur-euse"... et ce sera là mon premier constat :
Qu'avons-nous de si particulier pour que les femmes soient à ce point sous-représentées ?
Et, si c'était là le seul biais... il y en a tant d'autres.

Après 30 d'évolution dans ce métier, je propose une véritable introspection.
Que dis-je ? Une catharsis !!
J'aborderai des sujets sociétaux, mais également des aspects socio-économico-professionnels.
Mais, aussi un peu de technique. Car nous, Développeurs/euses, nous adorons nous compliquer la vie pour paraitre toujours plus des incontournables. Hors, personne n'est irremplaçable, et le mythe du Cowboy coder macho n'a pas encore disparu :(

L'idée est de faire réfléchir tout le monde à la place des uns et des autres dans cet univers particulier qu'est la création de logiciels.

TestContainers: turning the Pyramid of Tests upside down en fr

Docker has changed the world of IT (and is still changing it). It's not just about infra or ops. It really is devOps. And in devOps, there's dev.
Developers have everything to gain from using Docker, but sometimes it can seem complicated or cumbersome. That's where TestContainers come in. A technology available for a large number of development frameworks (Java/Kotlin, Python, NodeJs, .Net, Ruby...) . It will change the way you think about unit and integration tests.
As I will show you working code and tests, this will be a good opportunity to return to the true meaning of some magic terms and to talk about the famous test pyramid, once again.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

Monads without Maths, but with Cats (live coding) en fr

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Workshop: Practical guide to Monads for those who don't like maths en

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

the code:
https://github.com/guillaumeagile/MonadsFromTheTrenches_workshop
the slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Petits biais et grands travers du développement logiciel en

Faire partie de la grande famille des développeurs... quoi de plus rassurant? Nous aurons du travail à l'infini.
Oh, vraiment?

Nous savons coder, nous savons faire ce que les autres ignorent. Nous sachons. Nous dirigeons le monde. Car le logiciel dirige le monde.
Ils exigent de nous de la rapidité, pas de problème, nous livrerons à temps.
Puissants et obéissants, quel joli paradoxe.

Et pourtant, nous ne sommes pas au dessus de la mêlée.
Cette belle profession a besoin d'un bon coup de ménage, et surtout de balayer ses propres certitudes.
Let's do it!

Le monde n'est pas CRU(D), il est vivant! en

"Tu veux un logiciel? bah tu n'as qu'à prendre une base de données, un ORM, rajoute une API REST" (parce que c'est la mode) :
"et voila!"

Ajouter, modifier, supprimer... et se planter!
Tout ce qui vient avec le monde CRUD est une simplification de la réalité qui fait froid dans le dos. En étant aussi simpliste, les applications en deviennent horriblement complexe: transactions, verrous, exceptions, mutations... que des sources d'ennuis.

Venez voir comment on peut se débarrasser du mal à la base. Oui le monde évolue en permanence, et votre façon de programmer aussi.
Trop compliqué? En 1h30 de live coding, donnez naissance à du code fermé à la modification mais ouvert à l'infini.

Développeurs, réduisez votre charge mentale! en

Haaaaa, la charge mentale. Encore un truc de coach agile :D
Et si nous appliquions le concept aux développeurs et aux testeurs?
Imaginons nous réellement tout ce qui ce passe dans la tête de ceux ci? et surtout comment faire pour alléger la pression!
Des moyens, il y en a tellement.
Et pourtant, les développeurs eux même rechignent à simplifier leur code.
Allons voir ensemble pourquoi...

DDD: des outils pour le PO (mais pas que) fr

"Ce qui part en prod, c'est ce que le dev a compris", cette phrase n’est pas anodine et Guillaume l’utilise même souvent.

La relation entre le PO et les devs devrait être fusionnelle, au moins intense, animée, vivante et surtout permanente. Le PO doit parler le langage de son client et de son univers (le fameux "domaine"). Le dev doit parler le langage du PO.
Transitivité : Le dev doit parler le langage des utilisateurs, même et particulièrement dans son code. C'est un des piliers de DDD (Domain Driven Design). Mais sans le PO, le dev ne peut pas y arriver.
DDD vient avec une foule de sages conseils et d'outils extrêmement pratiques. Bien connus des développeurs, ils sont encore trop confidentiels dans le monde des POs/PMs.
Je vous invite à une rencontre...

L'invasion des mutants dans votre code (oui mais pour votre bien) fr

Tester c'est être agile, car c'est être confiant dans le produit qu'on livre. Vous faites probablement du TDD, ou au moins vous essayez d'écrire des tests. Vous vous vantez même d'avoir une bonne couverture. Mais résisterez vous à l'invasion des mutants?
Cette pratique de test peut faire peur, et pourtant... Quelle puissance! Quelle exigence!
Ce n'est pas (que) un outil de test, c'est (aussi) le gardien de la qualité de votre code. Et il ne tergiversera pas!
Etes vous prêts?

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander fr

Vous vous posez des questions sur les doublures de tests ou ce qui est généralement et abusivement dénommé “mocks”.
Venez apprendre et comprendre ce que sont les bouchons, dummy, stubs, fake, spy et mock. Quand et pourquoi les utiliser en situation réaliste, et l’usage d’un fake versus un spy.

Les monades sans les maths (live coding) en fr

Les monades ne sont pas qu'un OVNI mathématique, mais un vrai paradigme de programmation qui peut s'utiliser à peu près partout dans votre code.
Quel que soit le langage. Peu importe les situations.
Je vous propose une brève intro orientée "pratique" et surtout du live coding avec du TDD pour démystifier la librairie LanguageExt que nous avons en C# / .Net

Vous allez voir, ça ne mord pas, ça ne griffe pas.

Etes vous prêt à arrêter de coder avec des null, des if, des loops, des exceptions et tout autre cochonnerie ?

slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Qu'est ce qui rend une architecture logicielle testable ? en fr

On parle beaucoup de TDD, avec toujours, hélas, beaucoup de polémiques.
La qualité d'une solution logicielle, d'un produit fiable ne peut pas se résumer à une couverture de tests.
L'architecture logicielle a tant de style différents, tant de variations, de chapelles même.
Dans ce maelstrom de propositions, souvent trop influencées par des tendances de mode, laquelle choisir sous l'angle de la testabilité ?
Et d'abord, qu'est-ce qu'un bon test, selon votre humble avis ? Quelles sont les véritables caractéristiques de tests efficaces ?
Quelles sont vos attentes lorsqu'il s'agit de soumettre vos systèmes à des tests ? (couverture de code, expressivité, stabilité, vitesse de feedback, qualité des reports, lisibilité, maintenabilité).
Les tests sont aussi importants que votre code ? Sans aucun doute, ils subissent lourdement les conséquences de vos choix d'architecture logicielle.

Analysons ces questions cruciales, presque philosophiques, que dise je ! Je doute, donc je teste ? Ou l'inverse ?
L'intégration, la connascence et la testabilité sont des aspects cruciaux à questionner lorsque vient le temps des choix architecturaux.

TestContainers: la révolution pour vos tests unitaires en fr

Docker a bouleversé le monde de l'informatique (et est encore en train de le faire). Ce n'est pas qu'une affaire d'infra ou d'ops. C'est vraiment du devOps. Et dans devOps, il y a dev.
Les développeurs ont tout à gagner à utiliser Docker, mais parfois cela peut paraitre compliqué ou lourd. C'est là qu'entrent en scène les TestContainers. Une technologie disponible pour un grand nombre de frameworks de développement (Java/Kotlin, Python, NodeJs, .Net, Ruby...) que je vous propose d'utiliser pour vos tests unitaires et d'intégration ; une bonne occasion de revenir sur le vrai sens de ces 2 termes et de parler de pyramide de tests, une fois de plus.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using C# or Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre

OutsideIn and InsideOut: how hexagonal architecture rules them while simply isolates your tests en fr

There's no need for war between London TDDists and Chicago School TDDists.
And even if you're not a TDD enthusiast. You want to check that 'it works'.
To avoid the hell of end-to-end testing (E2E), all you need to do is think ahead and slice and dice your responsibilities.
This workshop will show you how, and more importantly, how to isolate 'technical problems' to the farthest edges of the hexagon: Where everything is simpler and more robust.
In C# or Kotlin, in Mob (Ensemble) Programming, anyone can join us and code without a computer.

OutsideIn vs InsideOut: comment l'archi hexagonale les départage en isolant les tests naturellement en fr

Plus besoin de se faire la guerre entre TDDiste London ou Chicago School.
Et même si vous n'êtes pas adepte de TDD. Vous voulez vérifier que "ca fonctionne".
Pour ne pas vous lancer dans l'enfer des tests bout en bout (E2E), il suffit de réfléchir un peu et découper les responsabilité finement.
Cet atelier vous montrera comment, et surtout comment isoler les "problèmes techniques' aux confins de l'hexagone. Là où tout est plus simple et surtout plus robuste.
En C# ou Kotlin, en Mob (Ensemble) Programing, tout le monde peut coder avec nous sans ordinateur.

Atelier complémentaire avec l'introduction à l'Architecture HExagonale et le coeur métier.