Pruebas Unitarias Limpias

1. No escribas código de producción hasta tener un test que falle. 2. No escribas más test del necesario para fallar. 3. No escribas más código de producción del necesario para pasar el test. El ciclo es: Rojo → Verde → Refactorizar. Los tests escritos después del código son a menudo incompletos: testean lo que escribiste, no lo que el código debería hacer.

// TDD cycle for a discount calculator

// ── Red ─────────────────────────────────────────
function test_no_discount_for_regular_users():
    calc = new DiscountCalculator()
    assert calc.apply(100.0, "regular") == 100.0  // fails — class doesn't exist

// ── Green ───────────────────────────────────────
class DiscountCalculator:
    function apply(price, tier):
        return price  // simplest code to pass

// ── Refactor ────────────────────────────────────
// Next test drives the next behavior:
function test_10_percent_off_for_premium_users():
    calc = new DiscountCalculator()
    assert calc.apply(100.0, "premium") == 90.0

Los tests limpios son Rápidos (milisegundos — sin BD, sin red), Independientes (ningún test prepara estado para otro), Repetibles (mismo resultado en cualquier entorno), de Validación automática (pasan o fallan — sin lectura humana), Puntuales (escritos justo antes del código de producción). Un conjunto de tests lento y dependiente del orden es uno que los desarrolladores dejan de ejecutar.

class TestUserService:
    function test_create_user():
        db = RealDatabase.connect("localhost:5432")  // slow!
        service = new UserService(db)
        user = service.create("Alice", "a@t.com")
        savedUserId = user.id  // ← shared state!

    function test_find_user():
        user = service.find(savedUserId)
        assert user.name == "Alice"  // depends on prev test

class TestUserService:
    function setup():
        db = new FakeDatabase()   // fast, in-memory
        service = new UserService(db)

    function test_create_returns_user_with_given_name():
        user = service.create("Alice", "a@t.com")
        assert user.name == "Alice"

    function test_find_returns_null_for_unknown_id():
        result = service.find("unknown-id")
        assert result == null

Cada función de test debe verificar un concepto. Múltiples aserciones por test significan múltiples modos de fallo: cuando falla, no sabes qué concepto se rompió. Usa nombres de test descriptivos como documentación: test_inactive_users_cannot_place_orders indica la regla que se está testando. Los futuros desarrolladores leerán los tests para entender el comportamiento, no el código fuente.

function test_user():
    user = new User("alice", "alice@test.com")
    assert user.name == "alice"
    assert user.email == "alice@test.com"
    assert user.isActive == true
    user.deactivate()
    assert user.isActive == false
    user.setRole("admin")
    assert user.role == "admin"

function test_user_is_active_by_default():
    user = new User("alice", "alice@test.com")
    assert user.isActive == true

function test_user_becomes_inactive_after_deactivation():
    user = new User("alice", "alice@test.com")
    user.deactivate()
    assert user.isActive == false

function test_user_role_can_be_set():
    user = new User("alice", "alice@test.com")
    user.setRole("admin")
    assert user.role == "admin"

Divide el Test Dios — este test tiene 5 conceptos diferentes. Separa cada uno en su propia función con un nombre descriptivo que se lea como una regla.