Con la v0.20 el proyecto ya tiene historial: puedes volver a cualquier punto anterior y sabes quién cambió qué y por qué. Pero Git no responde a la pregunta que de verdad importa cada vez que tocas una línea: ¿sigue funcionando todo lo demás? Hasta ahora la respuesta la dabas a mano, arrancando python -m tareafacil, creando una tarea, marcándola, filtrando, guardando y saliendo, opción por opción. Eso cuesta cinco minutos, se hace mal a la tercera vez y se acaba omitiendo justo el día en que hacía falta. Esta lección construye la red de seguridad que falta: pruebas automatizadas que comprueban solas, en menos de un segundo, que el programa hace lo que debe. Verás el patrón que siguen todas las pruebas, las dos herramientas del ecosistema Python —unittest, que viene incluida, y pytest, la que usa todo el mundo—, qué merece la pena probar y qué no, y por qué la separación entre entrada/salida y lógica que hicimos en 04-04 era, en realidad, la preparación para este momento.

1. Por qué probar
2. Tipos de prueba
3. Qué hace probable a un código
4. El patrón AAA y el nombre del test
5. assert: la primera prueba
6. unittest, la biblioteca estándar
7. pytest, la herramienta del ecosistema
8. unittest frente a pytest
9. Qué probar y qué no
10. Cobertura
11. TDD: rojo, verde, refactorizar
12. TareaFácil v0.21: la carpeta tests/
13. Errores comunes y consejos
14. Ejercicios
15. Conclusión

Una prueba automatizada es simplemente código que ejecuta tu código y comprueba que el resultado es el esperado. Suena a trabajo extra, y lo es la primera vez; deja de serlo en cuanto sumas lo que cuesta lo contrario:

• Repasar el menú a mano cuesta minutos en cada cambio, y se hace peor con el tiempo: al principio compruebas los diez casos, a la décima vez solo el que has tocado, y el fallo aparece justo en otro.
• El miedo paraliza: sin pruebas, mejorar código que ya funciona parece una temeridad, así que nadie lo mejora y el proyecto se pudre.
• Una prueba es documentación que no miente: test_completar_iguala_hechos_a_dias explica el comportamiento esperado mejor que cualquier párrafo, y si el comportamiento cambia, la prueba falla.

La palabra clave es regresión: un fallo que aparece en algo que antes funcionaba. Las pruebas automatizadas son la única defensa práctica contra ellas, y son lo que permite refactorizar sin miedo, que es exactamente lo que haremos en Estilo y refactorización.

Este curso se centra en las unitarias, con alguna de integración, y por una razón práctica: son rápidas, señalan con precisión qué está roto y no dependen de la interfaz. Una prueba de sistema que recorre el menú se rompe en cuanto cambias un texto, y cuando falla no dice dónde está el problema. La proporción sana en cualquier proyecto es la misma: muchas unitarias, algunas de integración, muy pocas de sistema.

Aquí se cobra la deuda de Descomponer un programa en funciones, donde separamos la entrada y la salida de la lógica y dijimos que eso permitiría probar el código. Compara estas dos versiones:

La primera es imposible de probar de forma razonable: para ejecutarla hay que simular el teclado, y para comprobar el resultado hay que capturar lo que imprime. La segunda se prueba en una línea: progreso(2, 4) == 50.0. La regla que se deduce es la que ya conoces con otro nombre: las funciones que reciben datos y devuelven resultados son probables; las que hablan con el mundo, no. Por eso modelo.py y agenda.py no tienen un solo print, y por eso todo lo que se pueda comprobar vive ahí y no en interfaz.py.

Todas las pruebas del mundo tienen la misma estructura de tres pasos, conocida como AAA:

1. Arrange (preparar): crear los datos y los objetos que necesita la prueba.
2. Act (actuar): ejecutar exactamente una cosa, la que se está probando.
3. Assert (comprobar): verificar que el resultado es el esperado.

Y el nombre importa tanto como el contenido, porque es lo único que verás cuando la prueba falle. Un buen nombre dice qué se prueba y qué se espera: test_completar_marca_la_tarea_y_iguala_los_dias te ahorra abrir el fichero; test_1 o test_tarea no dicen nada. La convención habitual es test_<que>_<condicion>_<resultado esperado>, y no importa que quede largo: los nombres de las pruebas se leen, no se escriben a mano.

Antes de usar herramienta alguna, assert ya te permite comprobar cosas. Su forma es assert condicion, "mensaje si falla": si la condición es verdadera no ocurre nada, y si es falsa lanza un AssertionError con tu mensaje.

Guardado en un fichero y ejecutado, o pasa en silencio o revienta señalando la línea. Es un primer paso perfectamente válido, y también la razón de que en 08-02 dijéramos que el sitio natural del assert son las pruebas. Sus límites aparecen enseguida: se para en el primer fallo sin comprobar el resto, no agrupa nada, no da un informe y no hay forma de ejecutar solo una parte. Para eso están las herramientas.

unittest viene con Python, así que no hay nada que instalar. Sus pruebas son métodos que empiezan por test_ dentro de una clase que hereda de unittest.TestCase:

Cuatro piezas que conviene entender. setUp se ejecuta antes de cada método de prueba, de modo que ninguna prueba hereda el estado de otra —hay también tearDown, que se ejecuta después y sirve para limpiar—. Los métodos assertEqual, assertTrue, assertIn comprueban igualdad, verdad y pertenencia. Y assertRaises, usado con with, comprueba lo contrario de lo habitual: que el bloque sí lance esa excepción; si no la lanza, la prueba falla. Se ejecuta desde la carpeta del proyecto:

pytest no viene con Python, pero es lo que usa prácticamente todo el mundo, porque quita la ceremonia: no hacen falta clases y se comprueba con el assert normal.

Tres herramientas nuevas ahí. pytest.raises hace lo mismo que assertRaises. @pytest.mark.parametrize es la más rentable de todas: escribe una prueba y ejecútala con cuatro juegos de datos, que aparecen como cuatro pruebas independientes en el informe; sin ella habrías escrito cuatro funciones casi idénticas. Y fíjate en el último caso, (8, 4, 100.0): es un caso límite, más días hechos que previstos, exactamente el tipo de cosa que la parametrización invita a añadir.

Las fixtures son la forma que tiene pytest de preparar datos comunes, el equivalente del setUp. Se declaran con un decorador y se piden por nombre como parámetro:

Y hay una fixture incorporada que resuelve un problema muy real: tmp_path, una carpeta temporal distinta para cada prueba, que Python borra al terminar. Es lo que permite probar el guardado en fichero sin tocar el tareas.json de verdad:

Eso es una prueba de integración: comprueba que Agenda, to_dict, from_dict y el módulo almacen encajan entre sí. Y comprueba lo único que importa de la persistencia: que lo que entra vuelve a salir igual (un ciclo guardar → cargar, o round-trip).

Ambas son correctas y conviven: pytest ejecuta también las pruebas escritas con unittest. La recomendación práctica: aprende unittest porque lo encontrarás en proyectos antiguos y porque no requiere instalar nada, y escribe con pytest porque es más corto, más legible y su informe de errores te dice qué valor salió y cuál esperabas.

No se prueba todo: se prueba lo que puede romperse y duele. Para cada función merece la pena cubrir tres familias de casos:

• Casos normales: lo que ocurre el 90 % de las veces. Una tarea con 2 de 4 días da 50 %.
• Casos límite: los bordes, donde vive la mayoría de los fallos. Cero días hechos, agenda vacía, la lista con un solo elemento, más días hechos que previstos, textos con espacios o en mayúsculas.
• Casos de error: lo que debe fallar y cómo debe fallar. Una prioridad inventada tiene que lanzar TareaInvalida, no devolver None en silencio.

Y hay una trampa clásica: probar la implementación en lugar del comportamiento. Una prueba que comprueba que Agenda guarda internamente una lista llamada _tareas se romperá el día que cambies esa lista por un diccionario, aunque el programa siga funcionando perfectamente. Prueba siempre lo que promete la función —lo que devuelve, lo que lanza, cómo queda el objeto—, nunca sus tripas. La señal de alarma es fácil de reconocer: si al refactorizar sin cambiar el comportamiento se rompen las pruebas, las pruebas estaban mal escritas.

La cobertura mide qué porcentaje de tus líneas ejecutan las pruebas. Se obtiene con una herramienta externa:

El informe lista cada fichero con su porcentaje y las líneas que no se han ejecutado nunca, y ahí está su verdadera utilidad: descubrir ramas enteras que nadie prueba —típicamente los except—. Pero conviene entender su límite: la cobertura mide qué se ejecuta, no qué se comprueba. Un test que llame a todas las funciones sin un solo assert da el 100 % y no garantiza absolutamente nada. Un 90 % con pruebas que comprueban los casos límite vale infinitamente más que un 100 % vacío. Úsala para encontrar huecos, nunca como objetivo.

TDD (Test-Driven Development, desarrollo dirigido por pruebas) le da la vuelta al orden habitual: primero se escribe la prueba, y solo después el código que la hace pasar. El ciclo tiene tres pasos:

Escribir la prueba primero obliga a decidir qué debe hacer la función antes de pensar en cómo, y garantiza que la prueba de verdad comprueba algo: si nunca la has visto fallar, no sabes si funciona. No hace falta aplicar TDD siempre —en este curso no lo haremos—, pero hay un caso en el que es claramente la mejor opción: cuando arreglas un fallo. Escribe primero una prueba que lo reproduzca (rojo), arréglalo (verde) y esa prueba quedará para siempre impidiendo que el fallo vuelva.

Las pruebas viven en su propia carpeta, junto al paquete:

Los ficheros de tests/ son los que has visto en los apartados 6 y 7: test_modelo.py comprueba la validación de Tarea, la normalización del responsable y completar(); test_agenda.py comprueba el orden de ordenadas(), el filtro por responsable y el ciclo guardar/cargar con tmp_path. Y esta es una ejecución real, con un fallo de verdad:

La prueba en rojo es el caso límite (8, 4, 100.0): con más días hechos que previstos, progreso() devolvía 200 %. El informe de pytest lo dice todo: qué caso concreto falló, qué valor salió (200.0) y cuál se esperaba (100.0). El arreglo es una línea en modelo.py:

TareaFácil v0.21: ocho pruebas que se ejecutan en cinco centésimas de segundo y verifican lo que antes exigía recorrer el menú a mano. A partir de aquí, cada cambio se valida con un solo comando, y el proyecto acaba de ganar la red de seguridad que hacía falta para poder mejorarlo sin miedo. Existen además herramientas de integración continua que ejecutan estas mismas pruebas automáticamente en cada push al remoto; queda muy lejos de este curso, pero es bueno saber que el paso siguiente existe.

• Probar funciones que hacen input() y print(). No se puede. Extrae la lógica a una función que reciba datos y devuelva un valor, y prueba esa.
• Pruebas que dependen unas de otras. Cada prueba debe poder ejecutarse sola y en cualquier orden. Para eso están setUp y las fixtures.
• Tocar los datos reales. Una prueba que escribe en tareas.json te borrará el trabajo algún día. Usa tmp_path.
• Probar la implementación, o poner nombres como test_1 y test_tarea. Si al refactorizar sin cambiar el comportamiento se rompen las pruebas, estaban mal escritas; y el nombre es lo único que ves cuando algo falla.
• Perseguir el 100 % de cobertura. Es fácil de falsear y no garantiza nada. Cubre los casos límite y los de error, que es donde están los fallos.
• Consejo: cuando encuentres un fallo, escribe primero la prueba que lo reproduce. Te confirma que lo has entendido y evita que vuelva nunca más.

Esta función no se puede probar. Sepárala en dos —una con la lógica y otra con la conversación— y escribe dos pruebas con pytest para la parte lógica, incluyendo un caso límite:

Escribe las pruebas de Agenda.buscar(titulo), que devuelve la tarea con ese título (sin distinguir mayúsculas) o None si no existe. Cubre un caso normal, dos casos límite y comprueba también qué pasa con una agenda vacía. Usa una fixture para la agenda de ejemplo.

Convierte estas tres pruebas casi idénticas en una sola parametrizada, y escribe además una prueba del ciclo guardar/cargar usando tmp_path:

Solución 1.

El caso límite de las ocho horas exactas es el más valioso, porque es donde vive el error clásico: un >= en vez de un > cobraría recargo por una jornada normal, y solo esa prueba lo detectaría. Fíjate además en que la función de conversación quedó tan simple que ya no necesita prueba: lo único que hace es llamar a la que sí está probada.

Solución 2.

Las cuatro pruebas describen el contrato completo de buscar: encuentra, ignora mayúsculas, devuelve None cuando no hay coincidencia y no revienta con una agenda vacía. Ninguna mira cómo está guardada la colección por dentro, así que si mañana Agenda cambia su lista por un diccionario, estas pruebas seguirán pasando: comprueban el comportamiento, no la implementación.

Solución 3.

Tres pruebas se han convertido en una que sigue ejecutándose tres veces, y añadir un cuarto caso ahora cuesta una línea. La segunda prueba usa tmp_path para escribir en una carpeta temporal: jamás toca el tareas.json real, y la carpeta desaparece al terminar. Es una prueba de integración en toda regla, porque para pasar necesitan funcionar Agenda, Tarea.to_dict, from_dict y las dos funciones del almacén.

Una prueba automatizada es código que ejecuta tu código y comprueba el resultado, y su valor real es defenderte de las regresiones: fallos que aparecen en algo que antes funcionaba. Hay pruebas unitarias, de integración y de sistema, y la proporción sana es muchas de las primeras y muy pocas de las últimas. Lo que hace probable a una función es exactamente lo que separamos en 04-04: recibir datos y devolver valores, sin input() ni print() de por medio. Toda prueba sigue el patrón AAA —preparar, actuar, comprobar— y lleva un nombre descriptivo, que es lo único que verás cuando falle. Con assert ya se puede comprobar cualquier cosa, y sobre esa base se levantan las dos herramientas: unittest, incluida en Python, con clases TestCase, métodos test_*, assertEqual/assertTrue/assertIn/assertRaises y setUp/tearDown, ejecutada con python -m unittest discover; y pytest, que se instala con pip y prescinde de clases, comprueba con el assert normal, informa con detalle de qué valor salió y cuál se esperaba, y aporta pytest.raises, @pytest.mark.parametrize para ejecutar una prueba con muchos juegos de datos, fixtures para preparar lo común y tmp_path para probar ficheros sin tocar los datos reales. Se prueban los casos normales, los casos límite —donde están casi todos los fallos— y los casos de error, siempre contra el comportamiento y nunca contra la implementación. La cobertura sirve para encontrar huecos, no como objetivo: mide qué se ejecuta, no qué se comprueba. Y TDD —rojo, verde, refactorizar— es especialmente útil al arreglar un fallo: primero la prueba que lo reproduce, después el arreglo.

TareaFácil es ahora la v0.21: una carpeta tests/ con test_modelo.py y test_agenda.py, ocho pruebas que se ejecutan en centésimas de segundo y que ya han encontrado un fallo real —el progreso que superaba el 100 %— y lo han dejado arreglado y protegido para siempre. Con esto tienes las cuatro piezas que faltaban al terminar el módulo 7: documentación, gestión de errores, historial y pruebas. Queda una última cosa, y es la que separa un programa que funciona de un programa del que uno se enorgullece: cómo está escrito. Hay funciones en interfaz.py que han crecido hasta las cuarenta líneas, números sueltos repetidos por varios ficheros, nombres heredados de cuando el programa era un ejercicio y trozos de código duplicados. En Estilo, legibilidad y refactorización se arregla todo eso con PEP 8, con herramientas automáticas y con un catálogo de refactorizaciones —apoyándote, precisamente, en las pruebas que acabas de escribir.