Lights in the game! 2 for Scala

Question

I'm trying to do integration testing on Play! 2 for the Scala application. To do this, I need to download some devices in order to have the database in a known state before each test.

For the moment, I'm just calling a method that executes a bunch of Squeryl statements to load data. But declaring declarations declaratively, either using Scala DSL, or in a language such as JSON or YAML, is more readable and easier to use.

In this Java application example , I see that the fixtures are loaded from the YAML file, but the Scala equivalent is applied to the manula loading, as I am doing right now.

I also found this project , which is not very well documented, and it seems a bit more complicated than I would like - it is not even clear to me where the equipment data is actually announced.

Are there any other options for loading fixtures on Play! attachment?

Answer 1

Use Evolutions. Write the settings and blur script for fixtures in SQL, or use mysqldump (or the equivalent for your database) to export your existing test database as sql.

http://www.playframework.org/documentation/1.2/evolutions

I find that the most stressful way to test is to set everything up in the database in memory, which means the tests run quickly and run tests with Java using JUnit. I use H2DB, but there are a few errors that you need to keep track of. I learned it with difficulty, so this should save you some time.

Play has a good system for setting up and breaking the application for integration testing using the start (FakeAplication ()) {..}, and you can configure it for use in the memory database using FakeApplication (for additionalConfiguration = inMemoryDatabase ()) see:

http://www.playframework.org/documentation/2.0/ScalaTest

OutOfMemory Errors: However, when running significant test equipment several times, OutOfMemory errors occurred on my computer. This seems to be due to the fact that the implementation of the inMemoryDatabase () function by default creates a new randomly named database and does not clear the old ones between test runs. This is not necessary if you wrote the evolutionary scripts correctly, as the database will be empty and throttled between each test. Therefore, we redefined this behavior to use the same database, and the memory problems disappeared.

DB Dialog Box: Another problem is that our production database is MySQL, which has a number of incompatibilities with H2DB. H2DB has compatibility modes for several dbs, which should reduce the number of problems you have:

http://www.h2database.com/html/features.html#compatibility

Putting it all together, it becomes a little cumbersome to add before each test, so I extracted it into a function:

def memDB[T](code: =>T) = running( FakeApplication( additionalConfiguration = Map( "db.default.driver" -> "org.h2.Driver", "db.default.url" -> "jdbc:h2:mem:test;MODE=MySQL" ) ) )(code) 

Then you can use it (see example):

 "My app" should { "integrate nicely" in memDB { ..... } } 

In each test, a fake application will start, run the evolution of the script device settings, run the test, and then tear it off again. Good luck

Answer 2

Why not use a java example in Scala? This exact code should also work unchanged in Scala ...