TDD en C# : arrêtez d'avoir peur des tests et commencez à écrire du code dont vous n'avez pas honte

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Pourquoi "les tests d'abord" n'est pas du masochisme, mais un super-pouvoir

\n\n

Imaginez : vous écrivez du code, tout fonctionne. Vous êtes heureux. Un mois plus tard, vous revenez sur le projet, vous modifiez une ligne – et tout casse. Ça vous dit quelque chose ? Bienvenue dans le club des développeurs qui n'écrivent pas de tests. Imaginez maintenant une autre réalité : vous modifiez le code, vous lancez les tests – et en 10 secondes, vous savez que rien n'est cassé. Ce n'est pas de la magie, c'est le TDD (Test-Driven Development) – le développement piloté par les tests.

\n\n

Dans cet article, nous allons décortiquer le TDD avec l'exemple du C#. Pas de théorie ennuyeuse. Seulement de la pratique, du code et des cas concrets. Si vous pensez que le TDD est réservé aux "architectes purs" ou aux "monstres d'entreprise", vous allez être surpris. C'est un outil qui sauvera votre code et vos nerfs.

\n\n

Qu'est-ce que le TDD et comment fonctionne Red-Green-Refactor

\n\n

Le TDD ne concerne pas les tests. Il concerne la conception. Vous n'écrivez pas les tests après le code, mais l'inverse : d'abord le test, ensuite le code minimal qui le fait passer, et seulement ensuite le refactoring. Ce cycle s'appelle Red-Green-Refactor :

\n\n

Red – on écrit un test qui échoue volontairement (rouge).
Green – on écrit le code minimal pour que le test réussisse (vert).
Refactor – on améliore le code sans changer son comportement.

\n\n

Cela vous semble étrange ? Prenons un exemple. Supposons que nous ayons besoin d'une calculatrice avec une méthode d'addition. Habituellement, on écrit la classe, puis le test. En TDD, c'est l'inverse.

\n\n

Étape 1 : Red – on écrit un test qui va échouer

\n\n

using NUnit.Framework;\n\n[TestFixture]\npublic class CalculatorTests\n{\n    [Test]\n    public void Add_ShouldReturnSumOfTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(2, 3);\n        \n        // Assert\n        Assert.AreEqual(5, result);\n    }\n}

\n\n

On lance – le test échoue, car la classe Calculator n'existe pas. Rouge, c'est normal. Maintenant, notre objectif est de passer au vert.

\n\n

Étape 2 : Green – un minimum de code pour que le test réussisse

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // Implémentation minimale\n    }\n}

\n\n

Le test est vert. Youpi. Mais le code est encore moche. Passons à l'étape 3.

\n\n

Étape 3 : Refactor – on améliore sans casser

\n\n

À cette étape, on peut ajouter des vérifications, la gestion des exceptions ou modifier l'architecture. L'essentiel est que les tests restent verts.

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        if (a < 0 || b < 0)\n            throw new ArgumentException("Only positive numbers allowed");\n        return a + b;\n    }\n}

\n\n

Le test va-t-il échouer ? Oui. Il faut donc mettre à jour le test ou modifier la logique. En TDD, le refactoring est toujours un dialogue avec les tests.

\n\n

Comment choisir un framework pour le TDD en C# : NUnit vs xUnit

\n\n

En C#, il existe trois frameworks populaires : NUnit, xUnit et MSTest. Nous allons examiner les deux premiers, car ce sont les plus flexibles.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n