Durante los últimos 10 meses, los desarrolladores de edX han trabajado arduamente para aumentar la cobertura de pruebas automatizadas. Nuestras 2,491 pruebas unitarias de Python actualmente cubren el 87 % de las líneas en el repositorio de la plataforma edx. Estas pruebas, junto con nuestras pruebas de aceptación de Selenium y las pruebas unitarias de JavaScript, se ejecutan en cada solicitud de extracción, lo que nos permite validar rápidamente los cambios de código propuestos.
¿Cómo aumentamos la cobertura de las pruebas de menos del 50 % al 87 % en solo 10 meses? Parte de la respuesta es una herramienta llamada cubierta de diferencial.
En un flujo de trabajo típico, un desarrollador que trabaja en un proyecto grande puede realizar una solicitud de incorporación de cambios que cambia unas pocas docenas de líneas de código. Antes del cambio, la cobertura de la prueba puede haber sido del 72%; después, todavía podría ser del 72%. El tamaño del proyecto hace que sea difícil ver el efecto de una sola solicitud de extracción. Diff-cover le permite concentrarse en las métricas de calidad de una sola solicitud de extracción en lugar del proyecto en su conjunto.
Diff-cover mide líneas de código en un git diff. Para un cambio propuesto al código, le mostrará cuáles de las líneas modificadas carecen de cobertura. Esta es una idea simple, pero tiene implicaciones poderosas:
- Para los desarrolladores, diff-cover proporciona una métrica clara y alcanzable: si toca una línea de código, debe cubrirse.
- Para los revisores de código, diff-cover facilita la verificación de que los desarrolladores están escribiendo pruebas para todos los cambios de código.
Al centrarse en la cobertura diferencial, los desarrolladores pueden dar pasos pequeños y visibles para mejorar la cobertura global. Un compromiso particular podría aumentar global cobertura por sólo una fracción de un por ciento, pero todavía tienen 95% diff cobertura. De manera lenta pero segura, a medida que los desarrolladores escribieron pruebas para sus cambios de código, la cobertura global también comenzó a aumentar. Como resultado, pudimos detectar ciertos tipos de errores antes.
Más importante aún, otros desarrolladores comenzaron a contribuir a diff-cover y a tomar posesión de la herramienta. Por ejemplo, Cale generalizó la herramienta para respaldar verificaciones de "calidad" adicionales, y Sarina la amplió para informar violaciones de pep8 y Pylint en una diferencia. Muchos otros desarrolladores brindaron comentarios y sugerencias durante una prueba beta inicial de diff-cover. La herramienta se convirtió en un punto de partida para reexaminar nuestros estándares de prueba y revisión de código, lo que condujo a un cambio real en nuestra cultura de prueba.
Por supuesto, la medición de la cobertura todavía tiene algunas limitaciones importantes. En particular, la cobertura de alta diferencia no no Garantía de código libre de errores: en un sistema estrechamente acoplado, un cambio en un componente podría tener consecuencias no deseadas y de gran alcance en otras partes del sistema, incluso si el código modificado está cubierto al 100 %. En tales casos, las pruebas de integración pueden detectar errores que las pruebas unitarias podrían pasar por alto.
Si cree que diff-cover podría serle útil, consulte el proyecto: es de código abierto y disponible en GitHub. El código está diseñado para ser extensible a otros sistemas de control de versiones y verificadores de calidad, ¡así que siéntase libre de agregar funciones y hacer una solicitud de extracción!
Will Daly es ingeniero de pruebas en edX. Cuando no está promoviendo el desarrollo basado en pruebas u optimizando un clúster de Jenkins, disfruta correr junto a los ríos y minimizar la cantidad de cosas en su apartamento.
