Entrá y llevá tu progreso —ejercicios, medallas y Pokémon— a cualquier dispositivo. 🔄
Si tu cuenta ya tiene progreso guardado, se carga ese al entrar.
Entraste como . Tu progreso se sincroniza solo. 🔄
Test para 'dividir'. Verificá que dividir(10, 2) == 5 Y que dividir(x, 0) LANCE ZeroDivisionError. Si no lanza, tu test debe fallar con AssertionError. Pista: usá try/except ZeroDivisionError; si NO lanzó, hacé raise AssertionError(...).
🎯 Meta: escribir tests que de verdad cazan bugs: probar los casos límite (lo vacío, el cero, el negativo) y verificar que tu código lance el error correcto.
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.
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ó ✅")
💡 El caso "" (vacío) es el que más bugs descubre. Siempre incluilo. Lo mismo con listas vacías, el 0 y los negativos.
| Tipo de dato | Casos límite a probar |
|---|---|
| texto | vacío "", un solo carácter |
| número | 0, negativos, muy grande |
| lista | vacía [], un solo elemento |
| división | dividir por 0 |
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.
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ó ✅")
💡 En pytest esto se escribe más cortito con with pytest.raises(ZeroDivisionError):, pero la idea es la misma: verificar que el error ocurra.
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):`.
| Cosa | Para qué |
|---|---|
| casos límite | vacío, cero, negativo, un solo elemento |
| el caso vacío | el que más bugs esconde |
try/except en el test | verificar que el error SÍ ocurra |
pytest.raises(...) | la forma corta de lo mismo |
Practicá con los ejercicios de este tema. 💪
⚡ “Cualquiera prueba que funciona; un buen test prueba que no se rompe.”