TDD y pruebas automatizadas

📐 Fundamento

El ciclo TDD formal:

[Red] Escribir una prueba que falla
    ↓
[Green] Escribir el código mínimo para pasar
    ↓
[Refactor] Limpiar sin cambiar comportamiento
    ↓
[Repetir con siguiente prueba]

Reglas del TDD (Kent Beck):

1. No escribir código de producción a menos que sea para hacer pasar una prueba que falla.
2. No escribir más prueba que la suficiente para demostrar un fallo.
3. No escribir más código de producción que el suficiente para hacer pasar la prueba.

FIRST — principios de buenas pruebas unitarias:

• Fast: Cada prueba corre en milisegundos. El suite completo en segundos.
• Isolated: No dependen entre sí. Pueden correr en cualquier orden.
• Repeatable: Mismo resultado en cualquier entorno.
• Self-validating: Pass o Fail. No requiere inspección manual.
• Timely: Se escriben cuando el código existe (o antes, en TDD).

📐 Fundamento

Instalación y estructura:

pip install pytest

proyecto/
├── src/
│   └── pedido.py
└── tests/
    └── test_pedido.py

Estructura básica de una prueba:

# tests/test_pedido.py

def test_calcular_total_con_iva():
    # Arrange (preparar)
    pedido = Pedido()
    pedido.agregar(Platillo("pupusa de queso", 1.00), cantidad=3)
    
    # Act (actuar)
    total = pedido.calcular_total()
    
    # Assert (verificar)
    assert total == pytest.approx(3.39, rel=0.01)

El patrón Arrange-Act-Assert (AAA) organiza cada prueba en tres secciones claras.

Fixtures — reutilizar configuración:

import pytest

@pytest.fixture
def pedido_basico():
    pedido = Pedido()
    pedido.agregar(Platillo("pupusa", 1.00), cantidad=2)
    return pedido

def test_total_dos_pupusas(pedido_basico):
    assert pedido_basico.calcular_total() == pytest.approx(2.26)

def test_tiene_dos_items(pedido_basico):
    assert len(pedido_basico.items) == 2

Parametrización — probar múltiples casos:

@pytest.mark.parametrize("cantidad, precio, esperado", [
    (1, 1.00, 1.13),
    (2, 2.50, 5.65),
    (3, 0.75, 2.54),
])
def test_calcular_total_parametrizado(cantidad, precio, esperado):
    pedido = Pedido()
    pedido.agregar(Platillo("platillo", precio), cantidad=cantidad)
    assert pedido.calcular_total() == pytest.approx(esperado, rel=0.01)

Probar excepciones:

def test_pedido_vacio_lanza_error():
    pedido = Pedido()
    with pytest.raises(PedidoVacioError, match="El pedido debe tener"):
        pedido.enviar_a_cocina()

Ejecutar las pruebas:

pytest                     # todas las pruebas
pytest tests/test_pedido.py  # archivo específico
pytest -v                  # verbose (ver nombre de cada prueba)
pytest --cov=src           # con cobertura (requiere pytest-cov)

📐 Fundamento

unittest.mock en Python (incluido en la librería estándar):

from unittest.mock import Mock, patch, MagicMock

# Crear un mock básico
repo_mock = Mock()
repo_mock.guardar.return_value = True  # definir valor de retorno
repo_mock.buscar.return_value = None   # otro caso

# Verificar que fue llamado
repo_mock.guardar.assert_called_once()
repo_mock.buscar.assert_called_with(id=42)

Inyección de dependencias para facilitar testing:

# Difícil de testear (dependencia interna):
class PedidoService:
    def __init__(self):
        self.repo = MySQLPedidoRepository()  # acoplado a MySQL

# Fácil de testear (dependencia inyectada):
class PedidoService:
    def __init__(self, repo):  # puede recibir un mock en pruebas
        self.repo = repo

Patch — reemplazar temporalmente un módulo:

from unittest.mock import patch

def test_envio_email_al_confirmar():
    with patch('src.notificaciones.enviar_email') as mock_email:
        servicio = PedidoService(repo=Mock())
        servicio.confirmar_pedido(pedido_id=1)
        
        mock_email.assert_called_once_with(
            destinatario="cocina@laesquina.sv",
            asunto="Nuevo pedido #1"
        )

📐 Fundamento

Code coverage mide qué porcentaje del código fuente es ejecutado por las pruebas.

Tipos de cobertura:

Con pytest-cov:

pip install pytest-cov
pytest --cov=src --cov-report=html
# Genera reporte HTML en htmlcov/index.html

Objetivos típicos de cobertura:

• < 60%: Peligroso. Cambios pueden romper cosas sin detección.
• 60–80%: Aceptable para proyectos pequeños.
• 80–90%: Objetivo estándar para proyectos profesionales.

• 90%: Generalmente diminishing returns (cobertura del 100% es imposible en la práctica).

Importante: 80% de cobertura no significa que el 80% del código sea correcto. Solo que el 80% es ejecutado por las pruebas. Podés tener alta cobertura con pruebas que no verifican el comportamiento correctamente.

📐 Fundamento

Formato Gherkin:

# features/registrar_pedido.feature
Funcionalidad: Registrar pedido en La Esquina

  Escenario: Mozo registra un pedido válido
    Dado que el mozo "Juan" ha iniciado sesión
    Y que la mesa 3 está disponible
    Cuando el mozo agrega 2 pupusas de queso al pedido
    Y confirma el pedido
    Entonces el pedido aparece en la pantalla de cocina
    Y el estado del pedido es "en preparación"

  Escenario: Mozo intenta enviar un pedido vacío
    Dado que el mozo "Juan" ha iniciado sesión
    Cuando el mozo intenta confirmar sin agregar platillos
    Entonces el sistema muestra "Agrega al menos un platillo"

Implementación en Python con Behave:

# features/steps/pedido_steps.py
from behave import given, when, then

@given('que el mozo "{nombre}" ha iniciado sesión')
def step_impl(context, nombre):
    context.mozo = Mozo.autenticar(nombre, password="test")

@when('el mozo agrega {cantidad:d} pupusas de queso al pedido')
def step_impl(context, cantidad):
    pupusa = Platillo("pupusa de queso", 1.00)
    context.pedido.agregar(pupusa, cantidad)

@then('el pedido aparece en la pantalla de cocina')
def step_impl(context):
    assert context.cocina_mock.tiene_pedido(context.pedido.id)