Grails integration test - how to use different datasources for different test

724 views Asked by At

I am trying to figure out a way to execute certain integration tests against an in memory DB (H2) and others against our Oracle test DB. Maybe its my limited test writing experience but it seems that some tests (such as search querying) are more suited for in memory as I can control the data set queried, and others such as testing transactions/persistence would benefit from going against our REAL schema and DB (Oracle).

I can think of 2 approaches but do not know how to implement either:

  1. add a new test phase so that I can have integration-test-in-mem and integration-test (using oracle) and have different tests run in different phases and configure each for the different DB
  2. have each test control which datasource is used

I would prefer the first as its cleaner and I don't have to pollute my test with logic to control which datasource it uses.

Also, the second is not simply setting different datasources by domain - I want to reuse the same domain in different tests against different DBs.

Any ideas appreciated and if you've done this please share! We do use SPOCK.

2

There are 2 answers

0
user2863513 On

Here is a blog article I've found on adding custom test phases/types by Luke Daley. Has anyone implemented this? Now that I've read that and understand terminology better I think what I would like to do is set up new types - not phases. Unfortunately though since we are using spock we are already basically using a custom type. Though we could leave spock as one of the 2 types and potentially create a 'SPOCK-IN-MEM' type although this may require redefining the spock type which might not work. Any advice welcome. I would say that this seems to come up often enough (I've sen this question asked by others in other forums) that there should be a simpler way to go about it.

0
user2863513 On

One more finding. There is an environment plugin for spock which adds an annotation to have tests run ONLY for the environment annotated. Its reusing the ignored tests capability of spock and is quite small, simple, and clean. The only downside is its for spock which is not an issue for our group.

A simpler way of defining phases would be nice - like a naming convention. It would be nice to be able to define phases/types with just a directory naming convention such as test//. Just create the folders and away you go. Then you could control execution by just explicitly setting phase/type/env in args when running test-app.