January 16, 2010 § 4 Comments
Having GlassFish v3 usable in embedded mode made it easy to create a maven plugin with multiple goals (see this previous entry). This in turn makes it easy to configure the plugin for maven-driven unit testing. Here’s an example :
Now it’s certainly nice to be able to automate tests right from a single
pom.xml and not have to deal with starting, deploying, stopping the app server. It’s even better when the runtime starts fast and uses only the required memory (as it is the case with GlassFish v3), but what about running tests involving a database? If a database server needs to be started using external tools (or worse, manually) it’s a bit back to square “one”.
This is where JavaDB embedded can come in handy. The trick with an application server like GlassFish is that it’s not enough to use the embedded driver (
org.apache.derby.jdbc.EmbeddedDriver), you also need to reference an embedded JTA datasource. GlassFish v3 ships with one such datasource pre-configured:
jdbc/__TimerPool so lazy as I am, I simply reused this in by setup – using the following JPA persistence-unit enables my test to fire up an embedded (in-process) instance of JavaDB (no separate startup, no port used). As the names implies, this pool isn’t really a general purpose one (it’s used for by the Timer Service) so this is a bit of a hack. A handy one, but a hack.
<property name="eclipselink.target-database" value="DERBY"/>
You see here that I use the
drop-and-create-tables ddl generation strategy (
create-tables would work too) and consider the database to be volatile. The next step would be to run all of this in-memory and no longer write files to disk (which shouldn’t be that hard).