Una aplicación terminada necesita algo más que una ejecución afortunada. En esta lección comprobarás que los módulos colaboran correctamente y que los errores previstos conservan los datos. Después elegirás una ampliación pequeña con reglas y pruebas. El resultado será una base de trabajo que entiendes y puedes modificar con un criterio propio.
Recuperar los requisitos iniciales
Abre la hoja del primer capítulo. Tenías un alta válida, un código repetido, una cantidad negativa, una búsqueda sin resultados y una importación incorrecta. Ahora cada requisito puede convertirse en una comprobación concreta. Si has cambiado alguna regla durante el curso anótalo y explica por qué. No declares cumplido un requisito simplemente porque ya no lo recuerdas.
El proyecto conserva información entre órdenes mediante SQLite. Su formato de intercambio utiliza tres columnas y punto y coma. Las búsquedas comparan sin distinguir mayúsculas pero mantienen las tildes. La importación incorpora el lote completo o lo rechaza. Estas características deben aparecer tanto en las instrucciones como en las pruebas que preparas.
Probar la transacción completa
Guarda test_proyecto.py junto a los cuatro módulos. La primera prueba comprobará una propiedad importante: si un lote contiene un código ya existente no debe conservar tampoco un artículo válido insertado antes de encontrar el conflicto. La segunda verificará un intercambio CSV de ida y vuelta sin utilizar archivos personales.
from pathlib import Path
from tempfile import TemporaryDirectory
import sqlite3
import unittest
from modelo import crear_articulo
from almacen import conectar, agregar_varios, consultarclass PruebasProyecto(unittest.TestCase): def setUp(self): self.conexion = conectar(":memory:") self.addCleanup(self.conexion.close)
def test_lote_duplicado_se_revierte(self): inicial = crear_articulo("CU001", "Cuaderno", 3) agregar_varios(self.conexion, [inicial]) lote = [ crear_articulo("CA001", "Carpeta", 2), crear_articulo("CU001", "Otro cuaderno", 5), ] with self.assertRaises(sqlite3.IntegrityError): agregar_varios(self.conexion, lote) self.assertEqual(consultar(self.conexion), [inicial])
def test_csv_conserva_datos(self): original = [crear_articulo("LA001", "Lápiz; azul", 0)] with TemporaryDirectory() as carpeta: ruta = Path(carpeta) / "prueba.csv" escribir_csv(ruta, original) self.assertEqual(leer_csv(ruta), original)
def test_busqueda_sin_resultados(self): agregar_varios(self.conexion, [crear_articulo("CU001", "Cuaderno", 3)]) self.assertEqual(consultar(self.conexion, "tornillo"), [])
if __name__ == "__main__": unittest.main() «`
Ejecuta python -m unittest -v desde proyecto. Cada prueba utiliza una base en memoria independiente. addCleanup registra el cierre aunque el caso falle. TemporaryDirectory crea una carpeta temporal y la elimina al salir del bloque. Estas herramientas permiten repetir la comprobación sin preparar ni borrar manualmente tus archivos de trabajo.
Lo que demuestra cada caso
La primera prueba integra modelo y almacenamiento. No se conforma con observar una excepción: consulta después y compara el estado real. Esa segunda parte demuestra la reversión. Sin ella podrías tener una prueba correcta aunque el programa hubiera dejado CA001 guardado. Una propiedad de datos debe verificarse examinando los datos después de la operación.
La segunda prueba integra escritura, lectura y validación. El nombre contiene una tilde y el separador del formato. La cantidad es cero. Son elecciones deliberadas que comprueban reglas que podrían perderse al intercambiar. La igualdad de las dataclasses permite comparar los campos sin escribir una comprobación independiente para cada uno.
La tercera diferencia un resultado vacío de una excepción. No encuentra tornillos y eso es una respuesta válida. Si la conexión estuviera cerrada debería fallar por otra razón. Cada prueba expresa una conducta concreta y no pretende demostrar todo el programa. Conserva también las pruebas de modelo que desarrollaste en el capítulo catorce.
Añadir comprobaciones de aceptación manuales
Las pruebas automáticas no sustituyen completamente a utilizar la terminal. Revisa la ayuda, las comillas en nombres con espacios y la posición de –db. Ejecuta el programa desde una carpeta distinta con rutas explícitas. Comprueba que sabes identificar la base que estás utilizando sin depender de lo que muestra el explorador por casualidad.
Realiza además el ensayo de copia con la base cerrada. Abre el respaldo y localiza un registro conocido. Documenta las versiones de Python utilizadas y cualquier diferencia observada. El curso no promete compatibilidad con todas las configuraciones posibles: has construido una aplicación con un alcance concreto y debes conservar las condiciones bajo las que la has verificado.
Preparar unas instrucciones para otra persona
Crea por tu cuenta un archivo de texto con los requisitos, los nombres de los módulos y cinco órdenes de ejemplo. Incluye cómo inicializar, añadir, buscar, exportar e importar en otra base. Explica que el entorno virtual se reconstruye y que la base contiene datos que necesitan respaldo. No distribuyas tus archivos de prueba mezclados con una supuesta versión definitiva.
Esas instrucciones son una prueba de claridad. Si otra persona necesita preguntarte qué carpeta contiene app.py o por qué un código repetido no actualiza el artículo, falta información. Puedes empezar por leértelas tú mismo al día siguiente sin consultar el historial de trabajo. Anota cada supuesto que habías dado por evidente.
Elegir una ampliación que puedas verificar
Una buena siguiente mejora sería actualizar la cantidad de un código exacto. Antes de programarla decide qué ocurre si no existe, si la cantidad es negativa o si coincide con la actual. Añade un comando específico y utiliza parámetros en SQL. Escribe primero una prueba de cada caso y conserva la versión anterior hasta verificar el cambio.
Otra opción es incorporar un informe de artículos agotados. Esa ampliación aprovecha las consultas sin modificar datos. No intentes añadir a la vez interfaz gráfica, usuarios y sincronización. Cada nueva responsabilidad exige decisiones propias. Profundizar en una mejora pequeña te permitirá reconocer qué parte del sistema cambia y qué comportamientos deben permanecer iguales.
Errores habituales
Cambiar el código y las expectativas de las pruebas al mismo tiempo puede esconder una regresión. Revisa el requisito antes de modificar lo esperado. Tampoco des por terminada una mejora porque aparece un mensaje de éxito: consulta el estado guardado y vuelve a abrir la aplicación para comprobar la persistencia.
Copiar una solución que no puedes explicar limita tu capacidad para mantenerla. Cuando incorpores ayuda externa reduce el ejemplo, ejecuta sus pruebas y revisa sus efectos sobre archivos. Tu siguiente objetivo debe ser comprender una pieza nueva cada vez. El proyecto actual ofrece una referencia suficientemente pequeña para observar esas diferencias con detalle.
Lo que deberías recordar
- Comprueba el estado después de un error.
- Las pruebas de integración unen varias piezas.
- Documenta cómo ejecutar y recuperar la aplicación.
- Amplía una responsabilidad cada vez.
Ejercicio práctico
Ejecuta las tres pruebas de integración y añade una cuarta que rechace un CSV con códigos repetidos después de normalizar. Añade también una prueba que intente exportar a un destino existente y confirme que conserva su contenido anterior. Usa una carpeta temporal en ambas.
Completa los cinco requisitos de aceptación de la primera hoja y registra sus resultados. Ensaya la recuperación de una copia sin borrar la base original. Prepara las instrucciones mínimas para ejecutar el proyecto desde una carpeta nueva con el intérprete del entorno.
Elige una sola mejora y escribe tres criterios de aceptación antes de tocar el código. Guarda una copia de la versión actual, realiza el cambio y repite las pruebas. Si una comprobación falla averigua si has cambiado una regla deliberadamente o si has introducido un defecto. Conserva en el cuaderno la decisión y la evidencia que la justifica.
Vuelve a las lecciones que necesites y aplica una mejora pequeña al proyecto después de comprobar su comportamiento.
