Roles de Prueba Estándar

STR está disponible para Centos/RHEL desde Repositorio EPEL. Como primer paso instale todos los paquetes necesarios:

Puede instalar también la última versión desde el repositorio copr:

La salida de la prueba (bien salida stdout/stderr output, archivos de registro o pantallazos) es guardada de forma predeterminada en el directorio artifacts directory. Use la variable de entorno TEST_ARTIFACTS para elegir una localización diferente si lo desea:

Un sujeto de prueba es como llamamos a la cosa a ser probada. Para convertir a un sujeto de prueba lanzado, en un sistema instalado a probar, usamos El inventario dinámico de Ansible. Use el siguiente comando para habilitarlo:

Como puede ver por la manera es que se establece el inventario, las pruebas pueden contener su propio inventario, que define sus propias instrucciones para convertir un sujeto de prueba en uno o más sistemas comprobables.

Usted puede llamar siempre a las pruebas localmente. Muchas pruebas modifican o cambian el sistema contra el que están corriendo, de modo que téngalo en cuenta cómo invocar a las pruebas. los siguientes ejemplos invocan pruebas contra el mismo sistema en el que se extrae el repositorio git. Abajo hay más opciones para invocar pruebas contra otros sistemas totalmente formados e integrados, como un Atomic Host o una imagen contenedor sujeto de prueba_.

Hay más de una prueba presente en paquete del repositorio git. El sistema de prueba ejecutará cada libro de jugadas que coincidan con el glob tests/tests*.yml separadamente en un entorno limpio. La mayoría de las veces se utiliza un único archivo `tests.yml`coo punto de entrada principal. Para ejecutarlo use el siguiente comando:

Puede encontrar artefactos de salida de las pruebas en artifacts/ o o especificar un directorio concreto como este:

Usted puede filtrar que clase de pruebas están corriendo mediante el argumento --tags. Para ejecutar sólo pruebas que son adecuadas para sistemas clásicos instalados por yum o dnf puede usar un comando como:

Cuando corren por un Sistema CI System las pruebas se llaman de acuerdo a Prueba Estándar de Interfaz. Mire aquí para más detalles y variables estándar de invocación.

Cuando corre las pruebas de arriba, las pruebas asumen que el sistema a probar es el mismo que está pidiendo las pruebas. En concreto, las pruebas asumen que lo que hay que probar ya está instalado.

Un sujeto de prueba es lo que llamamos a la cosa a ser probada. Los RPMs son una clase particular de sujeto de prueba. Para convertir un sujeto de prueba en un sistema a ser lanzado e instalado usamos Inventario dinámico Ansible. Invoquemos las pruebas con un inventario y una versión específica de gzip:

Advertirá que el RPM es instalado en un sistema comprobable antes de llamar a las pruebas. Algunas pruebas contienen su propio inventario, que sus propias instrucciones para convertir un sujeto en prueba en uno o más sistemas comprobables. Pero en este caso usamos el inventario predeterminado standard-test-roles de /usr/share/ansible/inventory para hacer esto.

Otro ejemplo es usar un sujeto en prueba de una imagen contenedor. Este es también un entregable completamente formado e integrado. El sujeto en prueba de nuevo representa la cosa a ser probada. Para probar contenedores hay una dependencia adicional necesaria:

La imagen contenedor es sacada de un registro y lanzada usando un estibador por un Inventario dinámico Ansible.

Si observa de cerca advertirá que la imagen es extrae si no es ya local, lanzada como contenedor y luego se prepara para que se ejecuten las pruebas. La primera vez esto puede ser un poco más largo. No todas las pruebas son capaces de funcionar en cualquier entorno distinto de un contenedor. De hecho, para ciertas pruebas, el software a ser probado puede no estar incluido en el contenedor. Pero mucha de las pruebas para los paquetes centrales deberían trabajar aqui.

El argumento --tags filtra las pruebas que no son adecuadas para ejecutarse en un contenedor, bien porque el sistema funciona de manera diferente o los paquetes correctos no son instalables.

Vea en la sección Debug instrucciones sobre como acceder a un contenedor en funcionamiento y diagnosticar porque han fallado las pruebas.

The former example may seem a bit contrived, but the concept of a test subject starts to make more sense when you want to test a fully formed and integrated deliverable, such as Atomic Host. The test subject again represents the thing to be tested. The test subject in this case is a QCow2 image. To turn a test subject into a launched system ready to be tested, we use Ansible dynamic inventory.

If you watch closely you’ll see that the Atomic Host image is booted, and the tests run against the launched image. Not all tests are able to function in the somewhat different environment of Atomic Host, in fact, for certain cases, the software to be tested may not be included in the Atomic Host test subject. But most of the tests in core packages should work here.

Some tests contain their own inventory, that is their own instructions for turning a test subject into one or more testable systems. But in this case we use the default standard-test-roles inventory to do this.

The --tags argument filters out tests that are not suitable for running on an Atomic Host, either because the system functions differently, or the correct packages are not available on that system.

See the Debug section to learn how to diagnose why the tests failed, and log into the running Atomic Host.

To increase output verbosity use option -v or -vvv:

or for full verbosity:

To debug tests in a running container or atomic host use the TEST_DEBUG environment variable. After the playbook runs, you’ll see diagnosis information with a helpful command to log in.

For container you’ll see output like this:

For atomic host the instructions are a bit different:

Now you can easily connect using these commands. Use suggested kill command to finish the running instance when done with investigation.

This is the recommended role for running tests written via the Beakerlib Testing Framework as it supports all currenlty supported testing environments (atomic, classic, container). It also supports beakerlib-libraries which allow easy code reuse among multiple tests.

To use this role create tests.yml file with contents similar to the following snippet. The tests parameter should include the list of directories with your beakerlib tests.

The required_packages parameter can be used to list additional packages that need to be installed on the system to run tests. If you have required packages correctly specified in the beakerlib test metadata (in Makefile RhtsRequires stands for hard requirements, Requires for soft requirements) it is not necessary to list them again here.

Instead of manually listing all tests to be executed it is also possible to provide an fmf filter in the following way:

Filter can be used also if tests are stored directly in the git:

See Metadata for more info about filtering tests based on fmf metadata.

Basic role can be used for executing scripts or binaries as simple tests. For example the following tests.yml file will run binary --help as a shell command in the current directory and provide pass/fail based on its return code:

Here’s another example tests.yml file which fetches a single integration test from a shared repository and uses parametrizing to run it multiple times with different environment variables:

This role has been obsoleted by the BeakerLib role which provides similar functionality.

Pagure and Copr repositories: