Probar manualmente una función una vez no garantiza que siga funcionando después de modificarla. Una prueba automática guarda una comprobación para repetirla cuando quieras. Vas a utilizar unittest, incluido en la biblioteca estándar, para verificar reglas pequeñas. No necesitas instalar un marco adicional ni medir porcentajes para empezar a trabajar con rigor.
Elegir comportamientos observables
Una buena prueba expresa una regla del programa. «Una cantidad negativa se rechaza» es una regla. «La función usa una variable llamada resultado» describe una decisión interna que puede cambiar sin afectar al comportamiento. Comprueba resultados y errores que importan a quien utiliza la función, no detalles que solo reflejan cómo la has escrito hoy.
Empezaremos con tres categorías: una entrada normal, un límite aceptado y una entrada rechazada. Para cantidades serán tres, cero y menos uno. Después incorporaremos textos inválidos. Este pequeño conjunto no demuestra que el programa sea perfecto pero detecta errores frecuentes y documenta decisiones que de otro modo quedarían dispersas en explicaciones.
Preparar el código que vas a comprobar
Guarda la función leer_cantidad del capítulo anterior en reglas_prueba.py sin la demostración que imprime mensajes. Si conservas una demostración protégela con la condición __name__. Al lado crea test_reglas.py con el siguiente contenido. El prefijo test ayuda a descubrir pruebas mediante las herramientas de unittest.
import unittestclass PruebasCantidad(unittest.TestCase): def test_cantidad_normal(self): self.assertEqual(leer_cantidad("3"), 3)
def test_cero_permitido(self): self.assertEqual(leer_cantidad("0"), 0)
def test_negativo_rechazado(self): with self.assertRaises(ValueError): leer_cantidad("-1")
if __name__ == "__main__": unittest.main() «`
Desde esa carpeta ejecuta python -m unittest -v. Sustituye python por la ruta del entorno si es necesario. La opción detallada muestra los nombres de las pruebas. Debes ver tres comprobaciones correctas. Si no encuentra ninguna revisa el nombre del archivo, el prefijo test de los métodos y el directorio desde el que ejecutas.
Interpretar un fallo sin manipular la prueba
assertEqual compara un resultado con el valor esperado. assertRaises comprueba que se comunica la excepción indicada. Si una prueba falla no cambies su expectativa automáticamente para volver a ver una salida correcta. Primero consulta la regla. Puede estar equivocado el código o puede estar equivocada la prueba pero la decisión debe justificarse por el comportamiento deseado.
Haz un experimento: cambia temporalmente la condición de la función para rechazar cero. La prueba test_cero_permitido debería avisarte. Si no ocurre quizá no estás ejecutando el archivo que has modificado. Este experimento muestra que una prueba aporta información cuando es capaz de detectar un defecto real. Restablece la regla después de comprobarlo.
Aislar cada caso
Las pruebas deben poder ejecutarse en cualquier orden. Si una añade un artículo y otra depende de encontrarlo tendrás una relación oculta. Prepara los datos dentro de cada caso o mediante un método de preparación que se ejecute para cada prueba. Más adelante utilizaremos bases de datos en memoria para evitar depender del inventario guardado en disco.
No escribas pruebas sobre archivos personales ni sobre una base de producción. Una prueba puede repetir inserciones muchas veces o provocar errores a propósito. Utiliza datos inventados y ubicaciones temporales. El propio diseño del código debe facilitarlo: si una función recibe una ruta o una conexión puedes proporcionarle una alternativa de prueba sin modificar la aplicación entera.
Nombrar lo que esperas
Un nombre como test_1 no comunica nada cuando falla. test_codigo_con_espacio_interior_se_rechaza describe la regla y orienta la investigación. No es necesario redactar una frase enorme pero sí señalar el caso relevante. El nombre complementa al valor esperado y reduce el tiempo que tardas en comprender una salida de varias pruebas.
Las pruebas también sirven para aclarar dudas. Si no sabes qué debería ocurrir con una entrada vacía todavía falta una decisión de diseño. Resuélvela antes de escribir una expectativa arbitraria. El curso ha definido que un código vacío es inválido y que una consulta vacía muestra todo. La misma entrada puede tener significados distintos según la operación.
Incorporar una regresión
Una regresión es un comportamiento que funcionaba y deja de funcionar tras un cambio. Cuando encuentres un defecto añade primero una prueba que lo reproduzca. Comprueba que falla, corrige el código y repite el conjunto. De ese modo el error queda registrado y resulta más difícil introducirlo otra vez sin advertirlo.
No necesitas probar cada línea de forma aislada. Las funciones sencillas se verifican con casos concretos y las operaciones completas con pruebas de integración. En la última lección comprobaremos que una importación duplicada revierte todo el lote. Esa prueba examina una propiedad del sistema que no se demuestra comprobando solo la conversión de cantidades.
Errores habituales
Una prueba que no contiene ninguna comprobación puede pasar aunque el programa no haga nada útil. También puede engañarte una expectativa calculada con la misma función que estás probando. Escribe resultados conocidos de forma independiente. Si sumas tres y cinco sabes que esperas ocho sin pedirle a la función que construya ese ocho.
Evita introducir esperas, acceso a internet o dependencia de la fecha actual en estas primeras pruebas. Esas condiciones hacen que un caso pueda variar sin que el código cambie. Utiliza entradas explícitas y resultados determinados. Ya habrá tiempo de aprender técnicas para sistemas externos cuando tu proyecto realmente los necesite.
Lo que deberías recordar
- Prueba comportamientos observables.
- Incluye entradas normales, límites y errores.
- Cada caso debe ser independiente.
- Un defecto corregido merece una prueba de regresión.
Ejercicio práctico
Crea los dos archivos y ejecuta las tres pruebas. Añade una cuarta para el texto «tres» y una quinta para «2.5». Ambas deben comprobar ValueError. Guarda la salida de ejecución o copia en el cuaderno el número de casos y su resultado.
Introduce el defecto que rechaza cero y confirma que una prueba falla. Anota su nombre antes de restaurar la función. Después escribe una prueba para limpiar_codigo usando un código con espacios exteriores y minúsculas. La expectativa debe ser CU001.
Elige un fallo que hayas cometido en una lección anterior y conviértelo en una prueba de regresión. Describe la entrada mínima que lo reproduce y el resultado correcto. La práctica termina cuando puedes ejecutar todas las comprobaciones de nuevo sin introducir datos a mano y sin depender del orden en que se ejecutan.
Siguiente: Trabajar con fechas sin hacer cuentas a mano.
