Comenzaré con una confesión: como ingeniero de software, odié y evité escribir pruebas durante años. Me encontré con muchos proyectos polvorientos: algunos sin ninguna prueba, otros que tenían pruebas pero nunca se habían ejecutado como parte de las canalizaciones de CI/CD, y los últimos incluían una cobertura de pruebas realmente pobre.
Por un lado, hay muchas razones por las que deberíamos escribir exámenes, pero por el otro, hay más excusas (o “justificaciones”) por las que nos los saltamos.
Mientras aspiraba a ser un profesional, siempre estuve celoso de esos brillantes repositorios de código abierto con cobertura de prueba del 100% y soñaba con eso en mis repositorios del día a día. Hace cuatro años, mientras luchaba conmigo mismo sobre ese asunto, encontré cubierta diferencialun gran proyecto de código abierto con una misión simple: cubrir su propio cambios con las pruebas. Así es como lo describen los autores:
La cobertura diferencial es el porcentaje de líneas nuevas o modificadas que están cubiertas por las pruebas. Esto proporciona un estándar claro y alcanzable para la revisión de código: si toca una línea de código, esa línea debe quedar cubierta. ¡La cobertura del código es responsabilidad de cada desarrollador!
En pocas palabras, diff-cover supone que estás usando git y ejecutar una herramienta de cobertura. Usando git es fácil de conseguir su números de línea modificados y compárelos con los números de línea descubiertos de su herramienta de cobertura favorita. Casi todas las herramientas de cobertura pueden generar un formato XML unificado y genérico, sin importar cuál sea su lenguaje de código (Python, JavaScript, etc.)
En resumen, el proceso que he estado haciendo hasta ahora como parte del CI fue:
- Ejecute todas las pruebas con una herramienta de cobertura, utilizando el pytest y pytest-cov paquetes:
py.test -o junit_family=xunit2 --junitxml result.xml -xv --ff --cov-config=.coveragerc --cov=<my_package> --cov-report=xml --cov-report=term <tests_package>
(tenga en cuenta que creará cobertura.xml y resultado.xml archivos de informes).
2. Ejecute la herramienta de cubierta del diferencial, usando el cubierta diferencial paquete:
diff-cover coverage.xml --compare-branch=origin/master
que imprimirá algo como el siguiente resultado:
-------------
Diff Coverage
Diff: origin/master...HEAD, staged and unstaged changes
-------------
my_package/connections/snowflake_client.py (100%)
my_package/logic/celery_tasks/top_score_task.py (100%)
my_package/queries/build_algorithm_studio_dataframes.py (100%)
-------------
Total: 16 lines
Missing: 0 lines
Coverage: 100%
-------------
Como puede ver en el resultado anterior, hice cambios en 3 archivos diferentes y cada uno de ellos está completamente cubierto (tuve que agregar algunas pruebas nuevas y otras pruebas existentes ya cubrieron algunos de mis cambios).
Ver ese informe de cobertura diferencial en cada PR (Pull Request) ha hecho que todos se vuelvan adictos a lograr ese 100%. Queremos demostrar que somos responsables de nuestros cambios y que podemos cubrirlos, en lugar de ser percibidos como perdedores y obtener un porcentaje bajo. Además, como efecto secundario, hemos experimentado cambios incrementales más pequeños en los RP, que es otro mejores prácticas. Esto se debe a que ahora todo el mundo lo piensa dos veces antes de agregar líneas de código redundantes.
Después de utilizar esta metodología durante algunos años, vemos un aumento constante en los porcentajes de cobertura general de nuestros repositorios. Como resultado, también ha habido un aumento en nuestra estabilidad de producción.
Nueva acción de GitHub
Hace unos meses, mi talentoso colega Asaf Gallea Decidió aprovechar este éxito en una solución más simple pero más poderosa. nueva acción de GitHub. Esta acción aplica la misma idea que diff-cover y también genera un informe amigable como comentario en su solicitud de extracción, proporcionando enlaces a líneas descubiertas en caso de que se haya perdido algo. La nueva acción también le permite establecer un umbral de cobertura mínimo (predeterminado en 80%); de lo contrario, el comprobación del estado fallará y no podrá fusionar sus cambios:
En la imagen de arriba vemos el ejemplo del informe de acción de GitHub. Hay un umbral mínimo del 95 %, se cambiaron 20 líneas en esta solicitud de extracción, 18 líneas están cubiertas por pruebas y dos líneas, 505 a 506, no están cubiertas. Dado que solo logramos una cobertura del 90% para los archivos modificados, la verificación de estado falló y es imposible fusionarlos en la rama maestra.
Tenga en cuenta que este informe no dice nada sobre la cobertura total del repositorio. Puede que sea bajo (60%) y, sin embargo, cualquier nuevo cambio debe superar el 95%, por lo que eventualmente la cobertura total aumentará.
Configure la acción pruebas-cobertura-reporte en su repositorio
¡Eso es todo! Ahora agreguemos esta acción a su repositorio en unos pocos pasos. Asumiré que es un proyecto de Python, pero también puedes agregarlo a proyectos en diferentes lenguajes de programación.
En la carpeta raíz del repositorio, cree el .github/workflows carpetas si aún no existe. Ahora bien, dentro del workflows carpeta vamos a crear un nuevo archivo llamado prueba.yml con el siguiente contenido:
# This workflow will install Python dependencies, run tests check the coveragename: Test with coverage
on:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v3
with:
python-version: 3.10
- name: Install Dependencies
run: |
python -m pip install --upgrade pip
pip install pytest pytest-cov
- name: Test with pytest
run: py.test -o junit_family=xunit2 --junitxml result.xml -v --ff --cov=<my_package> --cov-report=xml --cov-report=term <my_tests>
- name: Coverage Report
if: always()
uses: aGallea/tests-coverage-report@1.3.1
with:
min-coverage-percentage: '100'
fail-under-coverage-percentage: 'true'
cobertura-path: ./coverage.xml
junit-path: ./result.xml
asegúrese de reemplazar el
¡Eso es todo! Si abre una nueva solicitud de extracción para agregar este archivo, la acción debería activarse automáticamente y verá el informe:
Tenga en cuenta que, dado que no hay cambios en los archivos del paquete (archivos fuente), no hay detalles de cobertura que presentar. La imagen de arriba fue tomada de mi solicitud de extracción mientras agrego la acción de cobertura de prueba en uno de mis repositorios públicos.
Acabas de completar la primera acción (doble significado) que cambiará tu vida y te convertirá en un mejor desarrollador. Nuestra generación es adicta a los me gusta, los aplausos, los votos positivos y a los geeks como nosotros para mostrar nuestro profesionalismo con un informe de cobertura del 100% también. Nos encantaría recibir comentarios, sugerencias y solicitudes de funciones para esta acción que puedan mejorar su experiencia y motivación en las pruebas.