Je sais pas comment ça marche dans les autres langages de programmation que le C#, mais le principe est simple:
- tu écris la définition de la fonction et elle n'exécute encore rien
- tu écris le premier test qui décrit ton cas métier
- tu exécutes le test, les données en entrée et en attendu sont correct, mais la fonction étant vide, le test échoue
- tu modifies la fonction pour que le test passe vert
- tu écris un nouveau test qui décrit un 2ème cas métier
- tu exécutes le test, oh il échoue !
- tu modifies la fonction pour que les 2 tests passent vert
etc.

Ok, ça j'avais pigé :D

Mais je parle de cas concret.
T'as l'air d'en faire au boulot, du coup tu peux dire un peu concretement ce que ça donne dans la vraie vie ?
Genre comment tu colles ça sur ton modèle MVC ? Tu testes les fonctions de ton controlleurs ou tes modèles / tes managers / tes repositories etc ?

Concrètement, j'avais ce workflow à programmer:


Chaque tâche associée à un événement est une classe séparée de type abstrait "tâche".
Au dessus, il y a le "WorkflowOrganisateur" qui prend en entrée la description du workflow et a une liste de receveurs d'évènements.
Dans ma première implémentation, toutes les tâches sont vides et n'exécutent rien, voir génèrent une exception.

Mon premier test a été de générer l'évènement entré lié à UserLogin et d'attendre en sortie ce qui correspond à UserLogin.
J'ai corrigé le code de la tâche "UserLogin" pour que ça colle.

Dans ce cas, le test n'est pas un test unitaire, c'est un test d'intégration, on doit initialiser le "WorkflowOrganisateur" de telle manière qu'il ait la description du workflow, des mocks de receveurs d'évènement, s'attacher à ses sorties pour pouvoir les comparer, etc.

Pour que le code du test soit lisible, on utilise le schéma AAA (Arrange Act Assert) = Préparer Exécuter Vérifier.

Merci pour cet exemple plus concret.
Il faut vraiment que je creuse là dessus pour cadrer les futurs développements.