The only possible interactions with an Actor are sending messages and receiving back other messages. As the actor’s execution is made asynchronously, it can be hard to test without proper tools. Fortunately, Akka comes with a set of testing tools, the “TestKit”, that come handy when dealing with actors testing.

TestKit library

To use the Akka Testkit, you just have to add a dependency on it (usually for the “test” scope). In a classical SBT configuration, it should look as follow :

After reloading the SBT configuration, all the TestKit tools should be available in your project.

The TestKit class

One of the main tool provided by Akka Testkit is the TestKit class. Your test class can extend it and provide an ActorSystem and this system will be available implicitely in all your test cases. Note that you can also use the TestKitBase trait if you need a trait instead of a class.

This implicit Akka System will be used by the other Testkit tools and will allow to keep your code as simple as possible.

The TestActorRef class

The asynchronous model using by Akka can make it difficult to test. One can quickly have to do some complicated code with waits, timeouts,…

Fortunately, Akka Testkit comes with the TestActorRef class.

When you create an Actor with the TestActorRef, it will use a special message dispatcher called CallingThreadDispatcher that will execute the actor receive() method in the same thread it has been sent. Therefore, all your tell() calls will become synchronous and more easily testable.

In addition to making the actor message processing synchronous, the TestActorRef will give back a special ActorRef instance that allows you to access the underlying actor instance (which is not possible with standard Akka actors). It allows you to make assertions about some of the actor’s internal states.

The ImplicitSender trait

If you want to test an actor by sending him a message and expecting that it has replied to the sender, you can use the ImplicitSender trait. This trait will define an implicit ActorRef to a fake Actor and this ActorRef will be used automatically as the sender when you use the tell() (or !) method.

You can then use the expectMsg…() method available through the TestKit class to check wheter this fake actor has received any message.

At first sight, this exception is quite cryptic and it took me some time to understand why it was thrown and how to get rid of it.

What is optimistic locking ?

Optimistic locking is used when you don’t want to lock your data between the time you read it and the time you update it. It is based on the hypothesis that the value will probably not change in the database between reading and updating.

The benefit of using optimistic over pessimistic locking is that it does not require any lock on the database.

How Ebean manage optimisic locking ?

To understand the OptimisticLockingException, we need to dive into Ebean’s internals and look at how it handles optimistic locking.

Ebean has 2 strategies to manage optimistic locking (More info). The default strategy is called “All Column”. When Ebean executes an UPDATE SQL statement, it will include in the WHERE clause all the values it has read when retrieving the entity.

For example :

When retrieving a user like this

User user = User.find.byId(1)

The SQL statement will be something like

SELECT id, name, age FROM user WHERE id = 1

Let’s say it returns : 1, 'John', 25

If you update your entity and save it

user.setAge(26)
user.save()

The SQL statement will be something like

UPDATE user SET age = 26 WHERE id = 1 AND name = 'John' AND age = 25

This update statement will ensure that nobody has modified this data in the database since the entity has been retrieved. Ebean will then check if the number of records affected by this statement is 1 and if it’s 0, it means the data has been altered and it will throw the OptimisticLockException. That’s why you can see updated [0] rows in the Exception message.

Most of the time, this works well. It will succeed if the data has not been modified and fail if the data has been modified.

However sometimes it can fail even if the data has not been modified. This can happens for example if you have a column with type double and data containing a lot of decimals. It can happen that you retrieve in your Java code something like 0.46712538003907 but in fact, in the database, the data stored is something like 0.467125380039068. When updating, the Java value will be included in the WHERE clause and, as it doesn’t match the value stored in the database, the update will fail.

The solution

The easiest solution in this case is to use Ebean’s other strategy for managing optimistic locking. This second strategy is called “Version column”. For that, you can create a field in your entity that will be used to maintain its “version”. This field should have the @Version annotation. For example:

Database cleaning

To keep my tests really independent of each other, I systematically clean the database before each test.

One solution to achieve that is to create a new FakeApplication before each test. This can be done by replacing the @BeforeClass / @AfterClass annotations with @Before / @After and removing the static keyword in the methods’ declarations.

It will work well but unfortunately, this will have a bad impact on the execution time. It can be ok if you only have a few tests, but when the number of tests will grow, it can become problematic. It would be nice to find a more efficient solution.

To avoid creating a FakeApplication for each test, we could just execute directely some drop table and create table SQL scripts. This should be faster.

I found an easy way to do that by reusing the evolution script generated by the EbeanPlugin class. Here is how we can do this :

Note that if you have disabled evolutions, you will probably have to hack a little bit more to generate the create and drop scripts directly from Ebean. This is what is done in the EbeanPlugin.onStart() method.

IDE integration

Once you’ve correctly made your tests work with the FakeApplication, you might want to launch them directly from your IDE.

Why ?

Launching all your tests is easy with the command line. But when you want to launch a specific test class or method, it’s usually easier to use directly your IDE. You can then precisely select which tests to run, launch them in debug mode,…

The problem

If you try to do this on a test that use an Ebean entity, it will fail. Here is an example of what you will get :

java.lang.IllegalStateException: Class [class play.db.ebean.Model] is
enhanced and [class models.Company] is not - (you can not mix!!)

The problem is that your Model class is not enhanced by Ebean when you don’t launch your test from the Play console.

First solution : javaagent

Reading the Ebean reference guide , I found a way to automatically enhance your classes by using a specific javaagent.

All you have to do is to download Ebean, unzip it and then configure your IDE to add a JVM argument when launching the tests.

Here is how to do that with IntelliJ :

Go to the ‘Run’ / ‘Edit Configurations’ menu

Find the JUnit configuration under “Defaults”

Fill the ‘VM Options’ field with :

-javaagent:/path/to/ebean/ebean-2.7.3-agent.jar

You can then enjoy running tests from your IDE.

Second solution : IDE plugin

If you use IntelliJ, there is an easier solution to enable enhancement automatically on your model classes. You will find in the plugin repository the Ebean weaver plugin that will do exactly what we want.

You just have to install it, restart, check the ‘Build’ / ‘Ebean weaving’ menu and that’s all.

Note that such a plugin exists also for Eclipse.

Conclusion

I hope that with these small tips and tricks, you will be able to enjoy even more discovering Play 2.0.