Testing is a very important part of the software life cycle, but it is always underestimated or ignored. In general, it is recommended that device tests should not be dependent on data or a database, but integration tests are slightly different from each other and generally require a sufficient data set.
Ideally, for integration tests, there should be an integration server that has the proper database and sufficient data. If you do not have an integration server, all the same tools in the Play Framework is the easiest and easiest way to have the correct data before testing.
There are three types of tests in the Play Framework. Unit and functional tests are JUnit tests, and Selenium tests are also known as acceptance tests. All of these concepts are actually outside the core Play Framework model, with the exception of some really handy recipes. Therefore, to be honest, I could not understand the concerns about using this structure. For example, you can use your own Selenium syntax or use the tags #{selenium /} .
Lamps are also very convenient, and if you use them efficiently, they are very useful. I mean, you can share your data, i.e. users.yml, products.yml, etc., and download them yourself, and this gives you flexibility in your tests.
Until now, if you are not sure that you are using lights, than you could consider a data layout, but I do not prefer the data layout in integration tests. Here is an example of the mocking test data, and this is beyond the scope of the Play Framework;)
Mockito
To be honest, I don’t have the opportunity to play in the library, but if you have time, you should try.
Hope this answer helps you.