Cada Task se prueba automáticamente antes de poder fusionarse: tanto con pruebas unitarias específicas como con pruebas de extremo a extremo más amplias que ejercitan la aplicación en ejecución. La vista Testing muestra las pruebas de un proyecto con independencia de cualquier Task concreta.
Testing
Pruebas en el detalle de la Task
En la vista de detalle de una Task, el paso Test muestra el resultado de las pruebas unitarias del proyecto (cuántas pasaron, cuántas fallaron y la salida de los fallos) y el paso E2E muestra el resultado de los escenarios de extremo a extremo: acciones de usuario simuladas en la aplicación real en ejecución. Si Test o E2E falla, el paso Fix recibe los detalles del fallo, intenta corregir el problema y las pruebas se ejecutan de nuevo; esto puede repetirse automáticamente varias veces. Si las pruebas siguen fallando tras los intentos permitidos, la Task pasa a failed y los detalles del fallo quedan asociados a ella.
La vista Testing y sus pestañas
De forma predeterminada, la vista Testing tiene tres pestañas internas: History — Dashboard, History — Modules y Unit Tests. Existen más pestañas — Setup, Dashboard, Verdicts, E2E Plans, Scenarios, Integration Tests, Release Tests y el E2E Cockpit — pero permanecen ocultas hasta activarlas en la personalización de la navegación.
La pestaña Unit Tests
La pestaña Unit Tests tiene un botón Run unit tests, los totales de la última ejecución (passed, failed, skipped), una tabla Run History (fecha, passed, failed, total, duración) y, a la derecha, las pruebas individuales de la ejecución seleccionada con filtros como Passed y Failed. Un clic en una ejecución de Run History lista sus pruebas; al filtrar por Failed se lee el error de cada prueba fallida. Una ejecución que no se completó se marca como crashed con el motivo y un botón Ask AI to fix.
Veredictos de Verify
Tras las pruebas, el paso Verify vuelve a comprobar cada criterio de aceptación de la Task y registra uno de tres veredictos:
- passed — la comprobación se ejecutó y coincidió con lo esperado.
- failed — la comprobación se ejecutó y no coincidió; la salida indica qué se ejecutó, qué se esperaba y qué se obtuvo.
- unverifiable — la comprobación no pudo ejecutarse en absoluto (por ejemplo, necesita una instancia en ejecución que no está disponible). Esto nunca hace fallar la Task; el elemento figura como pendiente de verificación manual.
Build & Start/Stop
Permite lanzar una compilación del proyecto y después iniciar o detener una instancia en ejecución en su propio puerto dedicado, con independencia de las instancias aisladas que la Pipeline crea para las pruebas E2E durante una Task.
Estado en vivo y salida del terminal
Muestra de un vistazo si la instancia está en ejecución, compilando o detenida, y transmite en vivo la salida del terminal/consola; útil para confirmar que una compilación se completó o para diagnosticar por qué no lo hizo.
Detener una ejecución de pruebas en curso
Un conjunto largo de pruebas unitarias puede detenerse en cualquier momento directamente desde la vista Testing, sin esperar a que termine. Si el servidor de AITM se reinicia mientras hay una ejecución de pruebas en curso, la ejecución se interrumpe de forma segura: no quedará atascada en estado "running" en el siguiente arranque; el servidor lo detecta y lo limpia.
Presupuesto combinado de CPU/RAM para pruebas
Las pruebas unitarias y las pruebas E2E comparten un único presupuesto global de CPU y memoria que se adapta automáticamente al tamaño del servidor en el que se ejecuta AITM. Las pruebas se ejecutan de forma secuencial para que su uso combinado de recursos nunca sobrecargue el host; esto protege frente a caídas causadas por ejecutar varias cargas de pruebas a la vez.
Historial de veredictos E2E
Cada ejecución de pruebas de extremo a extremo registrada para este proyecto se conserva en la pestaña Verdicts (oculta de forma predeterminada), con su veredicto (pass, feature bug, environment error, etc.) y una línea de tiempo por la que se puede retroceder para ver cómo ha evolucionado la salud de las pruebas.
Menú desplegable del indicador de bugs
El menú desplegable del indicador de bugs en la barra superior muestra como máximo los 10 bugs más recientes, lo que lo mantiene rápido y legible incluso en proyectos con un largo historial de bugs. Siempre muestra un enlace Open Bug Section — incluso cuando la lista de elementos recientes está vacía — de modo que el menú nunca es un callejón sin salida; la lista completa de bugs queda siempre a un clic, sea cual sea el número de elementos recientes.
Consejos
- Conviene mantener detenida la instancia propia de un proyecto cuando no se está probando activamente: libera el puerto para las instancias E2E aisladas de la Pipeline.
- Conviene revisar el historial de veredictos E2E antes de volver a ejecutar un conjunto completo de pruebas: un error de entorno anterior puede explicar un fallo que en realidad no es un bug de código.