Casos límite y errores

Un test que solo prueba “lo fácil” da una falsa sensación de seguridad. Los bugs se esconden en los casos límite: la lista vacía, el cero, el número negativo, el texto sin nada. Un buen test va justo a buscarlos.

🧨 Dónde viven los bugs

def probar_largo(largo):
    assert largo("hola") == 4    # caso normal
    assert largo("") == 0        # ⚠️ caso LÍMITE: texto vacío
    assert largo("a") == 1       # caso mínimo

probar_largo(len)
print("pasó ✅")

🎯 Tabla de casos límite típicos

P: ¿Por qué son tan importantes los casos límite en los tests?
- Porque son los únicos casos que pytest ejecuta
+ Porque los bugs se esconden en los bordes: vacío, cero, un elemento
- Porque los casos normales nunca tienen errores
> El caso `""` o `[]` o `0` es donde más bugs aparecen: funciones que asumen que la lista tiene algo, que el número es positivo, etc. Los casos normales suelen andar; los límites, no.

💥 Testear que SÍ lance un error

A veces lo correcto es que la función falle. ¿Cómo lo probás? Esperás el error con try/except: si no salta, el test debe fallar.

def probar_dividir(dividir):
    assert dividir(10, 2) == 5
    try:
        dividir(5, 0)
    except ZeroDivisionError:
        return                      # ✅ bien: lanzó el error esperado
    raise AssertionError("dividir(5, 0) debería lanzar ZeroDivisionError")

probar_dividir(lambda a, b: a / b)
print("pasó ✅")

P: En un test, ¿cómo verificás que `dividir(5, 0)` lanza `ZeroDivisionError`?
- `assert dividir(5, 0) == ZeroDivisionError`
- `if dividir(5, 0): raise AssertionError()`
+ Llamás `dividir(5, 0)` dentro de un `try/except ZeroDivisionError` y si NO lanza, fallás el test manualmente
> Si el error **no** ocurre, el `except` no se activa y llegás al `raise AssertionError(...)` manual. En pytest también podés usar `with pytest.raises(ZeroDivisionError):`.

📝 Resumen

➡️ ¿Y ahora qué?

Practicá con los ejercicios de este tema. 💪