Skip to content

Latest commit

 

History

History
79 lines (59 loc) · 3.63 KB

README.adoc

File metadata and controls

79 lines (59 loc) · 3.63 KB
Raw

Testing Vert.x code

Tip
 The corresponding source code is in the step-4 folder of the guide repository.

Up to this point we have been developing the wiki implementation without testing. This is of course not a good practice, so let us see how to write tests for Vert.x code.

Getting started

The vertx-unit module provides utilities to test asynchronous operations in Vert.x. Aside from that, you can use your testing framework of choice like JUnit.

With JUnit, the required Maven dependencies are the following:

link:pom.xml[role=include]

JUnit tests need to be annotated with the VertxUnitRunner runner to use the vertx-unit features:

@RunWith(VertxUnitRunner.class)
public class SomeTest {
  // (...)
}

With that runner, JUnit test and life-cycle methods accept a TestContext argument. This object provides access to basic assertions, a context to store data, and several async-oriented helpers that we will see in this section.

To illustrate that, let us consider an asynchronous scenario where we want to check that a timer task has been called once, and that a periodic task has been called 3 times. Since that code is asynchronous, the test method exits before the test completes, so making that test pass or fail also needs to be done in an asynchronous fashion:

link:src/test/java/io/vertx/guides/wiki/database/WikiDatabaseVerticleTest.java[role=include]

  1. TestContext is a parameter provided by the runner.

  2. Since we are in unit tests, we need to create a Vert.x context.

  3. Here is an example of a basic TestContext assertion.

  4. We get a first Async object that can later be completed (or failed).

  5. This Async object works as a countdown that completes successfully after 3 calls.

  6. We complete when the timer fires.

  7. Each periodic task tick triggers a countdown. The test passes when all Async objects have completed.

  8. There is a default (long) timeout for asynchronous test cases, but it can be overridden through the JUnit @Test annotation.

Testing database operations

The database service is a good fit for writing tests.

We first need to deploy the database verticle. We will configure the JDBC connection to be HSQLDB with an in-memory storage, and upon success we will fetch a service proxy for our test cases.

Since these operations are involving, we leverage the JUnit before / after life-cycle methods:

link:src/test/java/io/vertx/guides/wiki/database/WikiDatabaseVerticleTest.java[role=include]

  1. We only override some of the verticle settings, the others will have default values.

  2. asyncAssertSuccess is useful to provide a handler that checks for the success of an asynchronous operation. There is a variant with no arguments, and a variant like this one where we can chain the result to another handler.

Cleaning up the Vert.x context is straightforward, and again we use asyncAssertSuccess to ensure that no error was encountered:

link:src/test/java/io/vertx/guides/wiki/database/WikiDatabaseVerticleTest.java[role=include]

The service operations are essentially CRUD operations, so a JUnit test case combining all of them is a fine way to test:

link:src/test/java/io/vertx/guides/wiki/database/WikiDatabaseVerticleTest.java[role=include]

  1. This is where the sole Async eventually completes.

  2. This is an alternative to exiting the test case method and relying on a JUnit timeout. Here the execution on the test case thread waits until either the Async completes or the timeout period elapses.