Integration testing with Play

Part six of a series

In Play, integration testing is very simple and the whole framework lends itself to writing good quality tests. However, setting them up can be confusing at times and there’s a few gotchas to be overcome.

Here we will briefly go over the tests configured in /tests/

Functionally testing endpoints:

Before we start implementing our endpoints we’re going to start by defining our tests. We do this by creating a test class for our controller and extending WithServer.

In our case, the requirement is for the promotion to close after a certain time. This means we’re going to need a way of mocking the time in such a way that our tests are robust. We can do this by using Guice to bind Clock to a mock instance:

We’re going to break up each of our tests into three 3 sections in a BDD fashion. Firstly we define our context, then when we invoke an event, and we should expect a certain outcome.

Here’s an example:

1. Given we’re at some arbitrary point in time before the end date
2. When a request is made to “/”
3. Then the request should be successful

Now, when we run the test we get the following response:

This is of course because the route doesn’t exist yet, so let’s create it by adding this line to conf/routes:

And let’s also create the charity controller and implement our index method:

Now, when we run the test we get a positive output:

Writing functional tests for the database with Ebean ORM

To test the database integration we start by standing up a fake application by extending Play’s WithApplication class. We then use this to supply us with an instance of the class we want to test in our @Before method, in this case CharityRepository.

(Note, one caveat here is we have to clean the contents of the charity table to remove the data added in our evolution scripts. This won’t be required if your evolution scripts do not contain insert statements.)

Now, we can start writing tests.

1. We create 4 rows in the charity table
2. When we query for all rows in the charity table
3. Then we check the result is 4

We can use Intellij to create the husk of our method so the test compiles.

Now, when we run the test we get the following output:

Time to fill out the implementation:

Here, we’re using a helper method to wrap the query in a context specifically defined for database calls. This way we’re not blocking Play’s default thread pool.

On our second run of the test we get the following output:

Success!

Gotchas:

Sometimes it is required to override specific properties when testing. This can be done by creating a separate config file which is referenced in your tests by including this in your build.sbt:

Make sure to add include “application.conf” at the top of the new conf file to inherit from your original!

Next >> Running a Play app with Docker locally and debugging with IntelliJ