Compartir Códgo de Pruebas

Motivación

Con el fin de realizar que el flujo de trabajo de CI sea confiable y eficiente, es crucial mantener la cobertura de pruebas en buen estado en todo momento. Compartir código de prueba entre varios paquetes (incluso dentro de varias ramas del mismo paquete) puede contribuir significativamente a:

  • Prevenir la duplicación del código de prueba

  • Minimizar el mantenimiento de las pruebas

  • Capturar incompatibilidades a tiempo

En general, las pruebas definen el funcionamiento del software, y la funcionalidad básica de muchos paquetes no cambia con frecuencia. Nos esforzamos por mantener la retrocompatibilidad siempre que sea posible. Por lo tanto, parece natural que, para estos componentes, las pruebas que protegen la especificación puedan cambiar a un ritmo más lento que las ramas de la distribución.

Consulte la discusión de ci-list completa para algún contexto más.

Implementación

Almacene el código de prueba en su repositorio preferido y haga referencia a las pruebas desde el archivo yaml de dist-git. Existe además un espacio de nombres especial tests dedicado a almacenar pruebas de integración de Fedora CI:

Utilizar fedpkg para clonar repositorios rápidamente desde el espacio de nombres de las pruebas:

fedpkg clone tests/shell

tmt

Habilitar pruebas desde un repositorio remoto utilizando tmt es directo:

discover:
    how: fmf
    url: https://src.fedoraproject.org/tests/shell.git

Consulte el paso preparación de documentación para más detalles.

Ejemplos

A continuación se muestran algunos ejemplos de la vida real en los que compartir el código de prueba puede aumentar la eficiencia a largo plazo.

SELinux

Varios componentes del espacio de usuario de SELinux comparten la cobertura de pruebas en un único repositorio de pruebas selinux:

Ruby

Otro ejemplo es Ruby: con aproximadamente 80 paquetes relacionados con Ruby on Rails, sería útil y eficiente contar con un único lugar para las pruebas de integración que verifiquen el correcto funcionamiento del framework tras actualizar cualquiera de estos paquetes. Por el contrario, mantener dichas pruebas en 80 repositorios sería una tarea tediosa.

Actualmente, el repositorio compartido tests/ruby aloja estas tres pruebas de integración de Ruby:

  • systemtap-static-probes-in-ruby - Ejercitar el API SystemTap de Ruby

  • tls-minimal-version - ensure Ruby OpenSSL respects crypto-policies

  • run-basic-rails-application - ejecutar una aplicación Rails simple

Consola

Hay varios intérpretes los cuales implementan la especificación POSIX:

  • bash

  • ksh

  • mksh

  • zsh

  • dash

Todos ellos comparten una cantidad significativa de cobertura de pruebas y no tiene sentido confirmar y mantener pruebas idénticas en cinco repositorios diferentes (+ posibles ramas).

Repositorio de pruebas de intérprete:

Bash plans/shell.fmf:

summary:
    Run relevant tests from the shell tests repository
discover:
    how: fmf
    url: https://src.fedoraproject.org/tests/shell
    filter: component:bash
execute:
    how: tmt
environment:
    PACKAGES: bash
    SH_BIN: bash

Inicio

Para crear un nuevo repositorio en el espacio de nombres de pruebas, utilice el comando request-tests-repo de fedpkg. Por ejemplo, para crear un repositorio de pruebas compartido llamado foo, disponible en https://src.fedoraproject.org/tests/foo.git

  • Configurar la autenticación para pagure según la ayuda en el comando request-repo

    fedpkg request-repo -h

  • Solicitar un nuevo repositorio con una descripción sensata

    fedpkg request-tests-repo foo "Descripción del repositorio"

Want to help? Learn how to contribute to Fedora Docs ›