¿Cómo utilizo el ejecutor de pruebas de características?

El test framework puede ejecutarse como un entorno de prueba en caja negra containerizado. La biblioteca del ejecutor de pruebas de características permite a las implementaciones de proyectos crear un contenedor que alberga todos los test framework pasos, configuración y permitir que las historias se ejecuten con la ayuda de un Rest API.

Configuración

El ejecutor de características de prueba 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
}

Ejecución en seco

Tanto las funciones de precarga como de carga se ejecutarán primero un Ejecución en seco de JBehave. La ejecución en seco verifica principalmente si hay pasos no implementados. Estos aparecerán como pasos PENDIENTES en los registros y API respuestas. Si alguna historia falla en la prueba en seco, no se copiará al directorio de historias, sino que se descartará y se registrarán o devolverán los errores.

REST Operaciones

Solo se puede ejecutar una única prueba a la vez. Si se intenta realizar otra prueba, se devolverá un mensaje de error indicando que otra ejecución está en progreso. Lo mismo se aplica a la carga, debido a que realizamos una prueba preliminar en la carga. Las cargas tampoco se pueden realizar cuando hay una ejecución en progreso. Para más detalles sobre el rest api refiérase a API.

Cómo absorberse en una implementación de cliente

Asumiendo que toda la necesaria custom Los pasos, definiciones e historias ya existen, por lo tanto, se deben completar los siguientes pasos para desplegar una versión en contenedor de las pruebas:

  1. Cree un nuevo módulo y añada la siguiente dependencia en su pom.xml:

    <dependency>
   <groupId>com.iconsolutions.test</groupId>
   <artifactId>test-fw-feature-executor</artifactId>
   <version>${latest-version}</version>
</dependency>

También añada cualquier dependencia de prueba que necesite para construir sus pasos de prueba y message definition s, o si esto ya existe en otro módulo, simplemente importe ese módulo en este.

  1. Este módulo necesita ser un proyecto 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>
..

  2. Crear un @Configuration clase y añada 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;
                }
            };
        }

  3. Actualice el configuración parámetros a valores apropiados.

  4. Agregue el contenedor a un despliegue y láncelo. Una vez que el contenedor esté en funcionamiento, la API está expuesto y puede ser visto en <host>/swagger-ui/index.html. El HTML y JSON las especificaciones están disponibles aquí.

  5. Agregue, visualice o ejecute historias utilizando 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 un informe no existe, se devolverá un 404 con un mensaje de error apropiado. La vista del informe siempre devolverá el último informe; los informes no se eliminan ni se archivan. == Abrir Api

HTML OpenApi especificación

Crudo Api Abierta especificación

Solución de problemas

  • Mis historias precargadas no aparecen cuando ejecuto /stories/get-stories.

    • Revise los registros en busca de errores durante la precarga, esto significa la ejecución en seco.failed para las historias particulares que faltan.

  • Mi informe de JBehave sigue mostrando el informe de ejecuciones anteriores.

    • Acceda a la url /stories/report-view y verifique si hay algún error devuelto, lo más probable es que se esté ejecutando un proceso y el nuevo informe aún no se ha generado.