Best practise for unit testing using an in memory db

[Atom Cong]

Hi, dear play gurus,

    I am creating some unit test using in-mem db. Usually what does people do to initialize dbs to a proper state?  I want to create some data entries every time before a testing, and clean everything up afterwards. Now it seems like I have to call my own functions explicitly in each unit test. Is there any machanism already doing that to isolate each unit test?

    Also, I found out from some old threads that I need to specify ""test.db.url" to separate  the testing database and production database connection. I was trying to find out from documentation the full spec to this "test.db.url"'s behaviour, but I got nothing. Can anyone point me to the reference if we have that somewhere?  Or maybe there is a page describing all configurable flags but I didn't find it?


Thank you very much.

[Ian Rae]

Assuming you are using Java, then have a look at the Computer Database sample.  Look at this file:

 samples\java\computer-database\conf\evolutions\default\2.sql

This populates the database with initial values.

[Alberto Souza]

Hi, I created a gist with an example about this. There is not a default way to do this using Play and, at least in my opinion, use a in memory db will be a problem for you. Probably will have different queries between your database and h2. https://gist.github.com/asouza/1b415e5582c7b9fff9b0

Alberto Souza

www.caelum.com.br
www.leanpub.com/playframeworknapratica
www.alots.wordpress.com/

[Atom Cong]

Hi, Alberto,

    Thanks for the info. Let me read and understand your code, that must be helpful. (and also I am using Java)

    Are you suggesting when doing unit test, you prefer to set up a real database for testing?  Or there is any other alternatives? 

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/l1XySAL1f5E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alberto Souza]

Not a real... But at least the same. If you run your project with Mysql, I think it is better to test with Mysql as well.

Alberto Souza

www.caelum.com.br
www.leanpub.com/playframeworknapratica
www.alots.wordpress.com/

[Ian Rae]

Using the same database platform is usually best. However if you find unit tests take far too long then you might want to use an in-memory database.  I use something even faster than H2, and then then use acceptance tests database queries against the target database platform.

Lots of debate on unit testing these days.  This article proposes relying on acceptance tests instead:
http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

--Ian

[Atom Cong]

Thanks for the tips Ian.

I was reading the computer-database example. I saw there were two sql scripts 1.sql and 2.sql. The thing that I don't understand, however, is that how the unit test, or the application loads these two scripts when needed?

I read the config files and some of the java implementations but still found nothing points to either 1.sql or 2.sql. :-(

Would you please explain a little how that works?  Or point me if there is already documentation some where?

Thank you very much~

[Daniel Manchester]

Hi,

The numbered SQL scripts (1.sql, 2.sql, ...) are database evolutions. An application developer writes them and places them in the designated directory. The Play framework determines when the database schema doesn't reflect recently added scripts and runs them.

In principal, then, since evolutions are about going from an empty schema to a working application database, it seems like they could be used to set up (and tear down) a database for testing purposes. The main technical matter you'd have to resolve is, how to move the responsibility of running the scripts from the framework into your test code.

Dan

[Atom Cong]

On Sat, Apr 26, 2014 at 12:17 PM, Daniel Manchester <dpmanc...@gmail.com> wrote:

Hi,

The numbered SQL scripts (1.sql, 2.sql, ...) are database evolutions. An application developer writes them and places them in the designated directory. The Play framework determines when the database schema doesn't reflect recently added scripts and runs them.

In principal, then, since evolutions are about going from an empty schema to a working application database, it seems like they could be used to set up (and tear down) a database for testing purposes. The main technical matter you'd have to resolve is, how to move the responsibility of running the scripts from the framework into your test code.

Thanks for the pointer!

Now I see how it works. And you are right: it seems not by default support separating prod and testing database schema. That could be pretty challenging to figure out how to make it working properly.

Again, thank you very much.