Una vez tuve una gran migraña. Fui al doctor. Cuando le decía al médico que me duele más la cabeza cuando la sacudo. El médico dijo : No la sacudas entonces.
Entonces, te digo. Si las pruebas de integración toman tiempo, no las ejecute … o al menos no las ejecute cada vez que construya.
El problema con tiempos de construcción largos es un efecto secundario de la pirámide de prueba tradicional. Así es como la mayoría de las empresas prueban su código
- ¿Cuáles son algunos ejemplos de aplicaciones reales de excepciones y subprocesos en Java?
- ¿Cómo colaborar en el desarrollo de software científico de código abierto? ¿Me puede dar ejemplos de software junto con esa descripción?
- ¿Cuál es el mejor software para la recuperación de datos del iPod?
- ¿Cuál es la diferencia entre Maven y Gradle?
- ¿Por qué los videojuegos son tan fluidos, rápidos y confiables en comparación con las aplicaciones de software?
La pirámide de prueba es como un cono de helado. Las pruebas unitarias solo cubren entre el 10 y el 20% del código. Las pruebas de Intgeration cubren el 40%, las pruebas de GUI automatizadas del 60% y luego las pruebas manuales cubren todo. Este es el resultado de ser flojo para las pruebas. Escriben algunas pruebas unitarias de “camino feliz” y lo tiran. Resulta que estas son pruebas de “tabla feliz”; es decir; El camino feliz es tan estrecho que podría ser una tabla. Luego aparece el cliente potencial y crea algunas pruebas centradas de requisitos de ruta feliz pruebas de integeración que prueban la ruta feliz real. Luego, el control de calidad viene en una prueba manual de inicio, y si tienen tiempo, automatizan las pruebas utilizando herramientas de automatización de GUI.
El problema aquí es que cuanto más alto subes en la pirámide, más escamosas y lentas se vuelven las pruebas. Lleva mucho tiempo ejecutarlos. Se necesita aún más tiempo para mantenerlos. Las personas dejan de mantener las pruebas, y luego fallan todo el tiempo, y luego todos las ignoran
Así debería verse la pirámide de prueba
La mayor parte de su código debe estar cubierto por pruebas unitarias El 80-90% del código debe estar cubierto por pruebas unitarias. Sus pruebas de nivel de servicio automatizadas deberían centrarse en probar escenarios centrados en el usuario y probar el 60% del código. Las pruebas de GUI automatizadas básicamente deberían probar si todo aparece donde deberían. No debe probar casos de negocios en pruebas de GUI. Las pruebas manuales deben reservarse para cosas como las pruebas de usabilidad
Entonces, ¿qué tiene esto que ver con los tiempos de compilación? Bueno, si superpone sus pruebas de esta manera, tendrá el lujo de organizar sus pruebas por etapas.
- Antes de cada verificación en el desarrollador ejecuta todas las pruebas unitarias en el módulo en el que está trabajando. Tenga en cuenta que esto es solo para el módulo en el que se está trabajando. No todo el conjunto de pruebas unitarias
- Todas las noches, su servidor CI ejecuta pruebas unitarias Integeration +. Estos pueden tomar más tiempo, como en el orden de las horas. Esto está bien porque se ejecuta solo una vez al día. Todos los desarrolladores no lo están ejecutando. Lo bueno de las pruebas de nivel de servicio es que es posible que pueda paralelizarlas para que todas se ejecuten durante la noche
- Todas las mañanas en el scrum, observa las pruebas de integración y aborda cualquier señal de alerta. Conseguir la construcción ecológica tiene prioridad sobre otras tareas
- Una vez a la semana, ejecuta pruebas de GUI automatizadas. Esto también llevará horas, pero pueden ejecutarse un sábado. deja que se rasgue mientras estás en casa con amigos y familiares
- El lunes por la mañana, el scrum analiza las pruebas de GUI y planea resolver los problemas.
¡Explosión! lo que tienes es una construcción rápida y pruebas exhaustivas.
