Documentation for a newer release is available. View Latest

¿Cómo uso el ejecutor de pruebas de funcionalidades?

El marco de pruebas se puede ejecutar como un entorno de pruebas de caja negra en contenedor. La biblioteca del ejecutor de pruebas de funcionalidades permite que las implementaciones de proyecto creen un contenedor que aloje todos los pasos del marco de pruebas, la configuración y permita que las stories se ejecuten con la ayuda de una API Rest.

Configuración

El ejecutor de funcionalidades de pruebas expone la siguiente configuración:

test-fw.executor {
  # The path where stories will be placed when uploaded and after passing dry run.
  stories-directory-path = stories

  # The path where stories will be temporarily placed for dry run during an upload.
  # Once the story has passed dry run they will be moved to the location configured by ${test-fw.executor.stories-directory-path}
  stories-staging-directory-path = staging

  # The directory on the classpath where existing stories will be uploaded into the filesystem.
  # These stories will also run through a dry run before being moved.
  stories-preload-path = stories

  # The directory where the preloaded stories will be placed once dry run has passed.
  # Target location will be ${test-fw.executor.stories-directory-path}/${test-fw.executor.stories-preload-tag}
  stories-preload-tag = default
}

Dry Run

Tanto las funciones de precarga como de carga primero ejecutarán un JBehave dry run. El dry run comprueba principalmente si hay pasos no implementados. Estos aparecerán como pasos PENDING en los logs y en las respuestas de la API. Si alguna story falla el dry run, no se copiará al directorio de stories, sino que se descartará y se registrarán o devolverán errores.

Operaciones REST

Solo se puede ejecutar una prueba a la vez. Si se intenta otra ejecución, devolveremos un mensaje de error indicando que hay otra ejecución en progreso. Lo mismo se aplica a las cargas debido al hecho de que hacemos un dry run en la carga. Tampoco se pueden hacer cargas cuando hay una ejecución en progreso. Para más detalles sobre la API rest, consulta API.

Cómo absorber en una implementación cliente

Suponiendo que ya existan todos los pasos, definiciones y stories personalizadas necesarias, entonces se deben completar los siguientes pasos para desplegar una versión en contenedor de las pruebas:

Crea un nuevo módulo y añade la siguiente dependencia a tu pom.xml:
```
<dependency>
   <groupId>com.iconsolutions.test</groupId>
   <artifactId>test-fw-feature-executor</artifactId>
   <version>${latest-version}</version>
</dependency>
```
También añade cualquier dependencia de prueba que necesites para construir tus pasos de prueba y definiciones de mensajes, o si esto ya existe en otro módulo simplemente importa ese módulo en este.

Este módulo debe ser un proyecto de contenedor, por lo que también necesitaremos tener el docker-maven-plugin para crear un contenedor:

<build>
    <plugins>
        <plugin>
            <groupId>io.fabric8</groupId>
            <artifactId>docker-maven-plugin</artifactId>
...

Crea una clase @Configuration y añade la siguiente clase y bean:

        /**
         * This represents a FeatureTestRunner for execution in the container environment.
         * Here we just need to override the config method to inject the @Configuration class needed
         * to bootstrap the app with steps and message definitions.
         *
         * This mirrors what you would define in a typical maven project.
         */
        public static class TestExecutorRunner extends AbstractExecutorTestRunner {
            @Override
            protected List<Class<?>> config() {
                return Collections.singletonList(TestConfig.class);
            }
        }

        /**
         * A bean to register the AbstractExecutorTestRunner which is responsible for launching the FeatureTestRunner.
         * All we need to override here is the runner method to register the AbstractExecutorTestRunner
         */
        @Bean
        public AbstractTestLauncher testExecutor() {
            return new AbstractTestLauncher() {
                @Override
                public Class<? extends FeatureTestRunner> runner() {
                    return TestExecutorRunner.class;
                }
            };
        }

Actualiza los parámetros de la configuración a valores apropiados.
Añade el contenedor a un despliegue y lánzalo. Una vez que el contenedor esté en ejecución, la API se expone y se puede ver en <host>/swagger-ui/index.html. Las especificaciones HTML y JSON están disponibles aquí.
Añade, visualiza o ejecuta stories usando la API. El informe de JBehave se expone en /stories/report-view, que redirige a los archivos JBehave alojados si existen. Si hay una ejecución en curso o no existe un informe, entonces se devolverá un 404 con un mensaje de error apropiado. La vista del informe siempre devolverá el informe más reciente; los informes no se limpian ni archivan.

Open Api

HTML OpenApi spec

Raw Open Api spec

Solución de problemas

Mis stories precargadas no aparecen cuando ejecuto /stories/get-stories.
- Revisa los logs por cualquier error durante la precarga; esto significa que el dry run falló para las stories particulares que faltan.
Mi informe de JBehave sigue mostrando el informe de ejecuciones anteriores.
- Accede a la URL /stories/report-view y verifica si se devuelve algún error; lo más probable es que haya una ejecución en progreso y que el nuevo informe aún no se haya generado.