Verificación de pruebas con conciencia de costos
Reduzca trabajo redundante y salida sin debilitar las comprobaciones necesarias. Elegir un mejor orden puede ahorrar tiempo de ejecución; los informes concisos ahorran contexto, pero no hacen que una prueba ya en ejecución sea más rápida. No afirme ahorros sin mediciones.
Planificar y ejecutar verificaciones
- Identifique componentes afectados, riesgos, requisitos del proyecto y comprobaciones apropiadas antes de ejecutar conjuntos costosos. Siga los requisitos explícitos del usuario y del proyecto, incluidas las comprobaciones obligatorias.
- Complete primero el cambio principal y la cobertura de regresión dirigida significativa. Diagnostique y corrija fallos de compilación o comportamiento con la comprobación relevante más estrecha. Luego estabilice las integraciones afectadas o los escenarios de extremo a extremo. Para escenarios compartidos nuevos o modificados, compare las expectativas con una referencia disponible; verifique y documente las diferencias intencionales por separado.
- Una vez que el cambio y las comprobaciones dirigidas sean estables, ejecute el conjunto final requerido, las comprobaciones estáticas y las compilaciones según corresponda. Reutilice un resultado exitoso solo mientras el código, las dependencias, la configuración, el entorno y el escenario relevantes permanezcan sin cambios.
- Después de una corrección, vuelva a ejecutar las comprobaciones afectadas. Repita el conjunto amplio cuando el impacto sea amplio, las dependencias cambien, los requisitos lo exijan o la corrección siga siendo incierta. No repita automáticamente un conjunto completo por cada fallo local.
- Para un fallo intermitente, conserve el primer fallo y vuelva a ejecutar la prueba sola; si es necesario, ejecute su conjunto en serie para investigar interferencias. Informe de inestabilidad no resuelta en lugar de tratar un pase posterior como prueba de que el fallo está corregido.
- Para cambios solo de documentación, verifique el diff, los enlaces relevantes y la sintaxis; ejecute pruebas de aplicación solo cuando sea necesario o relevante. Mantenga las mediciones de rendimiento aisladas de compilaciones y pruebas concurrentes que podrían distorsionar los resultados.
- Consulte trabajos de larga duración en intervalos razonables en lugar de leer repetidamente la salida sin cambios. Evite reiniciar trabajo solo para verificar el progreso.
Mantener la salida útil y acotada
Prefiera un ejecutor de proyecto existente o una instalación de informes del marco de trabajo. Capture la salida completa de stdout y stderr en un registro único y sin sobrescritura cuando sea apropiado, y devuelva un resumen conciso: resultado del comando y estado de salida, duración, recuentos de pruebas reconocibles incluyendo pruebas omitidas o ignoradas, y ubicación del registro. En caso de fallo, incluya los nombres de los casos fallidos y un extracto de diagnóstico acotado; inspeccione la parte relevante del registro completo si el resumen es insuficiente. Nunca infiera el éxito general a partir de recuentos parciales del conjunto: use el estado de salida real del comando e indique cuando no se pueda analizar un resumen. Preserve errores de lanzamiento, cancelación y comportamiento de señales. No apile envoltorios redundantes alrededor de un ejecutor existente.
Verificar la infraestructura de pruebas
Al crear o modificar sustancialmente un ejecutor de pruebas, envoltorio o herramienta de informes, pruebe la fiabilidad de sus resultados. Elija casos basándose en lo que la herramienta realmente hace y el riesgo de ocultar o tergiversar un fallo. Los casos útiles incluyen:
- Un fallo posterior después de un conjunto exitoso sigue siendo un fallo, con el estado de salida correcto.
- La salida completa se conserva incluso cuando los diagnósticos mostrados están acotados.
- Las omisiones, errores de lanzamiento, resúmenes no reconocidos e interrupciones se informan o propagan correctamente, cuando corresponda.
Ejercite el comportamiento observable, incluido el límite con el proceso de prueba subyacente. Adapte el análisis al marco de trabajo real y evite pruebas que simplemente dupliquen la implementación. Esto es verificación de la infraestructura, no un requisito para escribir pruebas para cada prueba individual. No reescriba ni vuelva a probar una herramienta existente fiable únicamente porque se use esta habilidad.
Escribir pruebas diagnósticas
Mantenga las pruebas exitosas silenciosas a menos que la salida de progreso sea útil. Los fallos deben identificar el caso, el comportamiento esperado y real, los parámetros relevantes y cualquier semilla aleatoria. Describa las cargas útiles grandes con longitudes, la ubicación del desajuste, extractos cortos o hashes en lugar de volcarlo todo. Habilite el detalle por iteración o trazas completas para el diagnóstico cuando sea necesario. Marque las omisiones explícitamente con razones y nunca convierta un fallo en una salida exitosa. Mejore las pruebas ruidosas existentes cuando trabaje en ellas en lugar de reescribir un conjunto saludable solo por formato.