TDD en C#: deja de temer a las pruebas y empieza a escribir código del que no te avergüences

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Por qué "primero las pruebas" no es masoquismo, sino un superpoder

\n\n

Imagina: escribes código, todo funciona. Eres feliz. Un mes después vuelves al proyecto, cambias una línea — y todo se rompe. ¿Te suena? Bienvenido al club de desarrolladores que no escriben pruebas. Ahora imagina otra realidad: cambias el código, ejecutas las pruebas — y en 10 segundos sabes que nada se ha roto. Esto no es magia, es TDD (Test-Driven Development) — desarrollo guiado por pruebas.

\n\n

En este artículo analizaremos TDD con ejemplos en C#. Sin teoría aburrida. Solo práctica, código y casos reales. Si piensas que TDD es solo para "arquitectos puristas" o "monstruos empresariales", te sorprenderás. Es una herramienta que salvará tu código y tus nervios.

\n\n

Qué es TDD y cómo funciona Red-Green-Refactor

\n\n

TDD no se trata de pruebas. Se trata de diseño. No escribes pruebas después del código, sino al revés: primero la prueba, luego el código mínimo que la supera, y solo después la refactorización. Este ciclo se llama Red-Green-Refactor:

\n\n

Red — escribimos una prueba que fallará (rojo).
Green — escribimos el código mínimo para que la prueba pase (verde).
Refactor — mejoramos el código sin cambiar su comportamiento.

\n\n

¿Parece extraño? Veamos un ejemplo. Supongamos que necesitamos una calculadora con un método de suma. Normalmente escribiríamos la clase y luego la prueba. En TDD es al revés.

\n\n

Paso 1: Red — escribimos una prueba que fallará

\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

Ejecutamos — la prueba falla porque la clase Calculator no existe. Rojo es normal. Ahora nuestra tarea es volverlo verde.

\n\n

Paso 2: Green — mínimo código para que la prueba pase

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // Implementación mínima\n    }\n}

\n\n

La prueba está verde. Hurra. Pero el código aún es feo. Pasamos al paso 3.

\n\n

Paso 3: Refactor — mejoramos sin romper

\n\n

En esta etapa podemos agregar validaciones, manejo de excepciones o cambiar la arquitectura. Lo importante es que las pruebas sigan en verde.

\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

¿La prueba fallará? Sí. Entonces hay que actualizar la prueba o cambiar la lógica. En TDD, la refactorización es siempre un diálogo con las pruebas.

\n\n