Pruebas continuas
Aprenda a utilizar las pruebas continuas en su aplicación Quarkus.
1. Requisitos previos
To complete this guide, you need:
-
Roughly 15 minutes
-
An IDE
-
JDK 17+ installed with
JAVA_HOME
configured appropriately -
Apache Maven 3.9.6
-
Optionally the Quarkus CLI if you want to use it
-
Optionally Mandrel or GraalVM installed and configured appropriately if you want to build a native executable (or Docker if you use a native container build)
-
La aplicación de bienvenida completada de la Guía de Inicio
2. Introducción
Quarkus supports continuous testing, where tests run immediately after code changes have been saved. This allows you to get instant feedback on your code changes. Quarkus detects which tests cover which code, and uses this information to only run the relevant tests when code is changed.
3. Solución
Inicie la aplicación "Getting Started " (o cualquier otra aplicación) utilizando:
quarkus dev
./mvnw quarkus:dev
./gradlew --console=plain quarkusDev
Quarkus se iniciará en modo de desarrollo como es normal, pero en la parte inferior de la pantalla debería ver lo siguiente:
--
Tests paused, press [r] to resume, [h] for more options>
Press r
and the tests will start running. You should see the status change down the bottom of the screen as they
are running, and it should finish with:
--
Tests all passed, 2 tests were run, 0 were skipped. Tests took 1470ms.
Press [r] to re-run, [v] to view full results, [p] to pause, [h] for more options>
If you want continuous testing to start automatically you can set quarkus.test.continuous-testing=enabled in
application.properties . If you don’t want it at all you can change this to disabled .
|
Now you can start making changes to your application. Go into the GreetingResource
and change the hello endpoint to
return "hello world"
, and save the file. Quarkus should immediately re-run the test, and you should get output similar
to the following:
2021-05-11 14:21:34,338 ERROR [io.qua.test] (Test runner thread) Test GreetingResourceTest#testHelloEndpoint() failed
: java.lang.AssertionError: 1 expectation failed.
Response body doesn't match expectation.
Expected: is "hello"
Actual: hello world
at io.restassured.internal.ValidatableResponseImpl.body(ValidatableResponseImpl.groovy)
at org.acme.getting.started.GreetingResourceTest.testHelloEndpoint(GreetingResourceTest.java:21)
--
Test run failed, 2 tests were run, 1 failed, 0 were skipped. Tests took 295ms
Press [r] to re-run, [v] to view full results, [p] to pause, [h] for more options>
Vuelva a cambiarlo y las pruebas se ejecutarán de nuevo.
4. Control de las pruebas continuas
There are various hotkeys you can use to control continuous testing. Pressing h
will display the following list
of commands:
The following commands are available:
[r] - Re-run all tests
[f] - Re-run failed tests
[b] - Toggle 'broken only' mode, where only failing tests are run (disabled)
[v] - Print failures from the last test run
[p] - Pause tests
[o] - Toggle test output (disabled)
[i] - Toggle instrumentation based reload (disabled)
[l] - Toggle live reload (enabled)
[s] - Force restart
[h] - Display this help
[q] - Quit
Se explican a continuación:
- [r] - Volver a ejecutar todas las pruebas
-
Esto volverá a ejecutar todas las pruebas
- [f] - Volver a ejecutar las pruebas fallidas
-
Esto volverá a ejecutar cada prueba que falle
- [b] - Activar el modo "sólo fallidas", en el que sólo se ejecutan las pruebas que fallan
-
Broken only mode will only run tests that have previously failed, even if other tests would normally be affected by a code change. This can be useful if you are modifying code that is used by lots of tests, but you only want to focus on debugging the failing one.
- [v] - Imprime los fallos de la última prueba realizada
-
Imprime los fallos en la consola de nuevo, esto puede ser útil si ha habido mucha salida en la consola desde la última ejecución.
- [p] - Pausa de las pruebas
-
Temporarily stops running tests. This can be useful if you are making lots of changes, and don’t want feedback until they are all done.
- [o] - Conmutar la salida de la prueba
-
By default test output is filtered and not displayed on the console, so that test output and dev mode output is not interleaved. Enabling test output will print output to the console when tests are run. Even when output is disabled the filtered output is saved and can be viewed in the Dev UI.
- [i] - Activar la recarga basada en la instrumentación
-
This is not directly related to testing, but allows you to toggle instrumentation based reload. This will allow live reload to avoid a restart if a change does not affect the structure of a class, which gives a faster reload and allows you to keep state.
- [l] - Activar la recarga en vivo
-
Esto no está directamente relacionado con las pruebas, pero le permite activar y desactivar la recarga en vivo.
- [s] - Forzar el reinicio
-
This will force a scan for changed files, and will perform a live reload with and changes. Note that even if there are no changes the application will still restart. This will still work even if live reload is disabled.
5. Pruebas continuas sin modo de desarrollo
It is possible to run continuous testing without starting dev mode. This can be useful if dev mode will interfere with
your tests (e.g. running wiremock on the same port), or if you only want to develop using tests. To start continuous testing
mode run mvn quarkus:test
.
La interfaz de usuario de desarrollo no está disponible cuando se ejecuta en el modo de pruebas continuas, ya que esto es proporcionado por el modo de desarrollo. |
6. Multi-module Projects
Note that continuous testing supports multi-module projects, so tests in modules other than the application can still be run when files are changed. The modules that are run can be controlled using config as listed below.
Está activada por defecto, y puede desactivarse a través de quarkus.test.only-test-application-module=true
.
7. Configuración de las pruebas continuas
Continuous testing supports multiple configuration options that can be used to limit the tests that are run, and to control the output. The configuration properties are shown below:
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Tipo |
Por defecto |
|
---|---|---|
If continuous testing is enabled. The default value is 'paused', which will allow you to start testing from the console or the Dev UI, but will not run tests on startup. If this is set to 'enabled' then testing will start as soon as the application has started. If this is 'disabled' then continuous testing is not enabled, and can’t be enabled without restarting the application. Environment variable: Show more |
|
|
If output from the running tests should be displayed in the console. Environment variable: Show more |
boolean |
|
Tags that should be included for continuous testing. This supports JUnit Tag Expressions. Environment variable: Show more |
list of string |
|
Tags that should be excluded by default with continuous testing. This is ignored if include-tags has been set. Defaults to 'slow'. This supports JUnit Tag Expressions. Environment variable: Show more |
list of string |
|
Tests that should be included for continuous testing. This is a regular expression and is matched against the test class name (not the file name). Environment variable: Show more |
string |
|
Tests that should be excluded with continuous testing. This is a regular expression and is matched against the test class name (not the file name). This is ignored if include-pattern has been set. Environment variable: Show more |
string |
|
Test engine ids that should be included for continuous testing. Environment variable: Show more |
list of string |
|
Test engine ids that should be excluded by default with continuous testing. This is ignored if include-engines has been set. Environment variable: Show more |
list of string |
|
Changes tests to use the 'flat' ClassPath used in Quarkus 1.x versions. This means all Quarkus and test classes are loaded in the same ClassLoader, however it means you cannot use continuous testing. Note that if you find this necessary for your application then you may also have problems running in development mode, which cannot use a flat class path. Environment variable: Show more |
boolean |
|
The profile to use when testing the native image Environment variable: Show more |
string |
|
The profile to use when testing using Environment variable: Show more |
string |
|
A comma separated list of profiles (dev, test, prod or custom profiles) to use when testing using @QuarkusTest Environment variable: Show more |
list of string |
|
The tags this profile is associated with. When the Environment variable: Show more |
list of string |
|
Controls the container network to be used when @QuarkusIntegration needs to launch the application in a container. This setting only applies if Quarkus does not need to use a shared network - which is the case if DevServices are used when running the test. Environment variable: Show more |
string |
|
Additional launch parameters to be used when Quarkus launches the produced artifact for Environment variable: Show more |
list of string |
|
Used in Environment variable: Show more |
|
|
Configures the hang detection in @QuarkusTest. If no activity happens (i.e. no test callbacks are called) over this period then QuarkusTest will dump all threads stack traces, to help diagnose a potential hang. Note that the initial timeout (before Quarkus has started) will only apply if provided by a system property, as it is not possible to read all config sources until Quarkus has booted. Environment variable: Show more |
|
|
The type of test to run, this can be either: quarkus-test: Only runs Environment variable: Show more |
|
|
If a class matches this pattern then it will be cloned into the Quarkus ClassLoader even if it is in a parent first artifact. This is important for collections which can contain objects from the Quarkus ClassLoader, but for most parent first classes it will just cause problems. Environment variable: Show more |
string |
|
If this is true then only the tests from the main application module will be run (i.e. the module that is currently running mvn quarkus:dev). If this is false then tests from all dependency modules will be run as well. Environment variable: Show more |
boolean |
|
Modules that should be included for continuous testing. This is a regular expression and is matched against the module groupId:artifactId. Environment variable: Show more |
string |
|
Modules that should be excluded for continuous testing. This is a regular expression and is matched against the module groupId:artifactId. This is ignored if include-module-pattern has been set. Environment variable: Show more |
string |
|
If the test callbacks should be invoked for the integration tests (tests annotated with Environment variable: Show more |
boolean |
|
Set additional ports to be exposed when @QuarkusIntegration needs to launch the application in a container. Environment variable: Show more |
|
|
A set of labels to add to the launched container Environment variable: Show more |
|
|
A set of volume mounts to add to the launched container Environment variable: Show more |
|
|
Additional environment variables to be set in the process that Environment variable: Show more |
|
About the Duration format
To write duration values, use the standard You can also use a simplified format, starting with a number:
In other cases, the simplified format is translated to the
|