Preguntas Más Frecuentes

¿Debería probar mi paquete?

¡Desde luego debería!

¿Cómo obtengo ayuda?

Use el canal #fedora-ci en IRC.

¿Por qué no confiar en %check?

%check y las pruebas realizadas en CI son complementarias. %check permite llevar a cabo diversas comprobaciones al tiempo de construir pero no detectará los requisitos perdidos, el fichero de configuración desaparecido y esa clase de situaciones que CI será capaz de probar y encontrar. Podríamos ver esto con %check haciendo unit-test (donde unit es el paquete) contra las pruebas de integración donde las pruebas se ejecutan sobre toda la distribución tal como se distribuye a n uestros usuarios. Así CI será capaz de encontrar errores de integración que la sección %check nunca será capaz de ver.

¿Dónde pongo mis pruebas?

Hay diversas opciones donde almacenar el código de prueba. Aquí están las principales ventajas y desventajas de cada aproximación: El código de prueba en dist git rpms namespace está enramado junto con los ficheros spect y así puede reflejar de cerca la funcionalidad. Las pruebas usadas a los largo de diversos componentes o SO pueden ser almacenadas en dist git test namespace para compartir el código de prueba y minimizar el mantenimiento. Las pruebas de recuperación desde un upstream project git son también posibles y soportadas por los roles estándar de prueba (rol fuente). Con el objetivo de evitar fallos inesperados de las pruebas originados por cambios más arriba es mejor hacer referencia a una confirmación específica en lugar de ramificar. La pruebas habilitadas en make check son ejecutada en un entorno diferente (buildroot). Esto es bueno para las pruebas unitarias pero no es recomendado para la nueva cobertura de pruebas de Nivel 1. Habilitar 'make check' en tests.yml solo si está probando rpm instalado.