Crear una API en Python es solo el primer paso. Para llevar un proyecto al nivel profesional necesitas tres componentes: el código funcional, la documentación con Swagger y las pruebas unitarias. Aquí aprendes a sumar el último pilar usando GitHub Copilot como copiloto de aprendizaje, no como muleta.

¿Por qué agregar pruebas unitarias a tu API de Flask?

Las pruebas unitarias confirman que cada endpoint responde como esperas y blindan tu proyecto cuando trabajas en equipo. Sin ellas, cualquier cambio puede romper algo sin que te enteres hasta producción.

En Python, el módulo unittest viene incluido en la librería estándar y es el punto de partida más directo para validar una API construida con Flask [00:38].

¿Qué son las pruebas unitarias en Python? Son scripts que verifican el comportamiento de funciones o endpoints específicos. Con unittest defines casos de prueba que ejecutan tu código y comparan el resultado contra lo esperado.

¿Cómo creo el archivo de prueba con ayuda de Copilot?

Todo arranca con un prompt claro dentro de Visual Studio Code: Necesito agregarle una prueba a esta API. ¿Cómo lo hago? Copilot reconoce el contexto de la conversación previa y sugiere crear un archivo dedicado [00:45].

El flujo recomendado es:

• Crear un archivo llamado test_app.py dentro de la misma carpeta del proyecto.
• Importar el módulo unittest y la app de Flask.
• Escribir una prueba unitaria para el endpoint /saludo, que responde a solicitudes tipo GET.
• Pegar el código sugerido por Copilot en el archivo recién creado.

Un detalle clave: ubicar el archivo dentro de la carpeta correcta evita problemas de rutas al momento de ejecutar las pruebas [01:20].

¿Qué aprendes al leer el código que sugiere Copilot?

Al revisar la respuesta línea por línea, identificas que import unittest carga el framework de testing nativo de Python. Esto te muestra qué paquetes son los más utilizados en el ecosistema y amplía tu vocabulario técnico sin tener que buscarlo aparte [01:45].

¿Cómo ejecuto la prueba unitaria desde la terminal?

Copilot indica el comando exacto: abrir una terminal, navegar al directorio donde vive test_app.py y correr la prueba con Python. Antes, conviene detener la API que corre con Swagger y limpiar el espacio de trabajo para evitar conflictos [02:15].

El comando que se ejecuta es:

bash python3 -m unittest test_app.py

Si usas una versión específica de Python, asegúrate de invocarla con python3 en lugar de python. La prueba corre en una fracción de segundo y, si todo está bien, verás el mensaje OK en consola [02:45].

¿Para qué sirve el parámetro -m en python -m unittest?

Aquí está el momento de aprendizaje real. En lugar de solo copiar el comando, le preguntas a Copilot directamente: ¿Para qué sirve el parámetro -m en el comando que acabo de ejecutar? [03:20].

La respuesta es concreta: el parámetro -m le indica a Python que debe ejecutar el módulo especificado como si fuera un script. En este caso, ese módulo es unittest, el framework de pruebas unitarias de Python.

¿Qué hace el flag -m en Python? Permite ejecutar cualquier módulo instalado como un script desde la línea de comandos, sin tener que escribir un archivo intermedio que lo invoque.

Un efecto colateral útil: al ejecutar la prueba, Python genera la carpeta __pycache__, que guarda los módulos compilados necesarios para que las pruebas corran más rápido la próxima vez [04:00].

¿Cómo escribir prompts mejores para Copilot?

Un consejo práctico que aparece en el flujo: cuida la gramática de tus prompts. Si escribes en español, incluye acentos y signos de puntuación correctos. Copilot interpreta mejor las instrucciones bien redactadas, sin importar que tú estés más acostumbrado a escribir prompts en inglés [03:35].

No se trata de copiar y pegar todo lo que sugiere la IA, sino de:

• Pedir explicaciones de cada parámetro o función que no entiendas.
• Validar el código sugerido antes de ejecutarlo.
• Aprovechar las respuestas para identificar módulos y patrones que se usan en proyectos reales.

El trinomio del commit perfecto

Con la API desarrollada, Swagger documentando cada endpoint y las pruebas unitarias validando el comportamiento, tienes los tres elementos que conforman un commit profesional [04:30].

Cuando trabajas en equipo y subes cambios mediante un pull request, lo ideal es que cada commit incluya:

1. El código funcional de la nueva feature o fix.
2. La documentación correspondiente, idealmente con Swagger u OpenAPI.
3. Las pruebas unitarias que respalden el cambio.

Este trinomio reduce fricciones en revisiones de código y te posiciona como alguien que entrega trabajo completo, no solo funcional. ¿Tú ya estás aplicando este flujo en tus proyectos? Cuéntame en los comentarios cómo lo haces.