When you start using the Play Framework 2 you will notice that there are a bunch of test helpers and entry points to set up your tests. That’s great! One might thinks that’s too good to be true. And in fact, when using the
FakeApplication test helper you can run into subtle problems which cause unreliable tests.
In the Play Framework documentation they show you that it is quite easy to set up a test with a
FakeApplication by the following code snippet:
1 2 3 4 5 6 7 8 9 10
So, you might think when you have many test methods you just copy this pattern and everything is fine. But that is not the case!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Here are two examples that
FakeApplication can be difficult to use:
- (Play-Scala 2.0.4) FakeApplication onStop not being called after Test
- [play 2.0.3] Two fakeApplication tests only one will succeed but the other throws error 500
I ran into the same problems that are mentioned in the first mailinglist posting. In the project where I’m using MongoDB together with Play 2 the tests with a
FakeApplication started to become unreliable. There were issues with cleaning up test data after and before each test method. Also the shutdown and restart of a
FakeApplication was sometimes error prone.
The best solution for this problems is to start one
FakeApplication per test class, not per test method. Here is the test helper class that I use for this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
You only need to inherit from it and every test has access to a running
FakeApplication. One disadvantage is that you have more work to clean up any data that is written for your tests into databases, filesystem or any other persistent system. But you get reliable integration tests and the tests are much faster because you only start one
FakeApplication per class and not dozens of them as in the per method approach
Beside this little issues that
FakeApplication can cause Play 2 offers great testing support.