This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Junit testing with Ant & HSQLDB in memory

Apr 4th, 2005, 01:22 AM

Does anyone use an in-memory HSQLDB database to test their business layer (facades, business delegates, etc)?

Right now I test my Hibernate DAOs and business delegates, running Junit via Ant. I use Hibernate's SchemaExportTask to create the schema before running the tests. The test case itself loads a Spring application context, and tests the various DAOs and facades. I'm currently using a MySQL db.

This works fine, but I'd like it to be faster and more elegant, and running it via HSQLDB in memory would be the ultimate way to do it. I could use a file-based instance of HSQLDB, but this wouldn't be any quicker/better than using MySQL.

The problem is, I'm not sure how to keep an in-memory instance of HSQLDB around between Ant tasks. For example, sure I can run the SchemaExportTask, but naturally that's pointless for a DB that only exists in memory for the duration of that task!

I could use a file-based instance of HSQLDB, but this wouldn't be any quicker/better than using MySQL.

The file based mode executes in the application's JVM so should be quicker than MySQL over a network, however, different DBs have subtle (and not so subtle) differences, so I wouldn't rely on this technique alone.

Comment

Does anyone use an in-memory HSQLDB database to test their business layer (facades, business delegates, etc)?

Right now I test my Hibernate DAOs and business delegates, running Junit via Ant. I use Hibernate's SchemaExportTask to create the schema before running the tests. The test case itself loads a Spring application context, and tests the various DAOs and facades. I'm currently using a MySQL db.

We use HSqlDB over here for unit-testing. MySQL DB (and others) are used only within the acceptance tests. As far as I see in the code we derive all test-cases from within the same test case. (In this case HibernateTestCase).

The application context is stored by a static parameter but guarded with the context location (we use diffrent context locations over here). If the context location changes the application context is reloaded.

To protect the test cases from each other (side effects if tear down fails!), the application context is also guarded by the actual test-case class. So potential side-effects due incomplete tear-downs are limited on a per test-case class level.

On tear-down all tables effected tables get cleared (special implementation by all DAO test cases).

The whole test-case is usally surounded by a programmatical transaction, so in case of failure there is usally nothing committed - except some few extense transaction scenarios when fiddeling with application transactions (using programmatic transactions).

By recycling the context the tests are really fast to do. The whole persistance / domain layer test suite consists of around 1000 test-cases and run within a minute. Compared to the acceptance tests running for minutes, this is quite a relief.

Our business objects are defined using totally abstract classes (interfaces in terms of java). So mostly the advanced Business services are tested in isolation utilizing jMock.

We plan to switch to TestNG and the new Spring support for test cases, so maybe you should check both, too. We expect some improvements in terms of control and simplicity. (The test code was original written starting with a pre-release Spring version.)

It claims that the object that I think is of type LocalSessionFactoryBean is in fact of type net.sf.hibernate.impl.SessionFactoryImpl. Yet, that's now how it is declared in the applicationContext.xml file.

Does anyone know what is going on here, and how I can get an instance of LocalSessionFactoryBean?

Comment

I am using an in-memory HSQLDB for unit-testing of HQL. Combined with a DBUnit dataset each unit test is rigged with a fresh db-instance. In the test setup I create with Hibernate Schemaexport the database with tables. Works perfectly. See http://www.cybersnippet.nl/blog/entr...with_in_memory for more info about the setup.