Skip to content

Latest commit

 

History

History
99 lines (57 loc) · 4.21 KB

JavaTest.md

File metadata and controls

99 lines (57 loc) · 4.21 KB
Raw

Testing your application

Writing tests for your application can be an involved process. Play supports JUnit and provides helpers and application stubs to make testing your application as easy as possible.

Overview

The location for tests is in the "test" folder. There are two sample test files created in the test folder which can be used as templates.

You can run tests from the sbt console.

  • To run all tests, run test.
  • To run only one test class, run testOnly followed by the name of the class i.e. testOnly my.namespace.MyTest.
  • To run only the tests that have failed, run testQuick.
  • To run tests continually, run a command with a tilde in front, i.e. ~testQuick.
  • To access test helpers such as FakeApplication in console, run test:console.

Testing in Play is based on sbt, and a full description is available in the testing documentation.

Using JUnit

The default way to test a Play application is with JUnit.

@test-simple

Note: A new process is forked each time test or test-only is run. The new process uses default JVM settings. Custom settings can be added to build.sbt. For example:

javaOptions in Test ++= Seq(
  "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9998",
  "-Xms512M",
  "-Xmx1536M",
  "-Xss1M"
)

Assertions & Matchers

Some developers prefer to write their assertions in a more fluent style than JUnit asserts. Popular libraries for other assertion styles are included for convenience.

Hamcrest matchers:

@test-hamcrest

Mocks

Mocks are used to isolate unit tests against external dependencies. For example, if your class under test depends on an external data access class, you can mock this to provide controlled data and eliminate the need for an external data resource.

The Mockito library is a popular mocking framework for Java. To use it in your tests add a dependency on the mockito-core artifact to your build.sbt file. For example:

libraryDependencies += "org.mockito" % "mockito-core" % "2.10.0" % "test"

You can find the current version number of mockito-core here.

Using Mockito, you can mock classes or interfaces like so:

@test-mockito-import

@test-mockito

Unit testing models

Let's assume we have the following data model:

@test-model

Some data access libraries such as Ebean allow you to put data access logic directly in your model classes using static methods. This can make mocking a data dependency tricky.

A common approach for testability is to keep the models isolated from the database and as much logic as possible, and abstract database access behind a repository interface.

@test-model-repository

Then use a service that contains your repository to interact with your models:

@test-model-service

In this way, the UserService.isAdmin method can be tested by mocking the UserRepository dependency:

@test-model-test

Unit testing controllers

You can test your controllers using Play's test helpers to extract useful properties.

@test-controller-test

Unit testing view templates

As a template is a just a method, you can execute it from a test and check the result:

@test-template

Unit testing with Messages

If you need a play.i18n.MessagesApi instance for unit testing, you can use play.test.Helpers.stubMessagesApi() to provide one:

@test-messages