For TestNG, what is the proper method for pre-populating the data source containing a complex model when it will be queried using Hibernate?

Question

I wish to write tests for our Seam Framework-based web site's internal search engine that uses Hibernate + Lucene indexing (on DB2) for queries. What is the best solution for populating the data source before the TestNG suite is run when the project's data model is quite complex considering entity relationships and field constraints? For some test cases, at least a dozen database tables would require rows relating to each other in order to adhere to the data model's constraints. Ideally Hypersonic would be used since in-memory usage will shorten our build process' running time.

Hopefully my question is clear as it's difficult to formulate a complete picture of my problem without throwing up a massive wall of descriptive text and proprietary code. Basically, creating each entity programmatically (instantiating all objects via Hibernate's Home object, setting each property, persisting to data source, and committing transaction in a FacesRequest @Test) is too unwieldy given the data model and the populate.sql script we already have written (and is executed on DB2 for running our JBoss-hosted web site locally) can't be used on Hypersonic! And every TestNG example I come across online or in books contain brutally simple data sets that don't indicate a clear approach to my problem.

Answer 1

To create your complex data and, at the same time, hide complex setup, my advice is to use builder pattern which is described here It allows you to create stuff like

Person person = PersonBuilder.validPerson()
                             .withAddress(AddressBuider.validAddress())
                             .build();

About h2 and db2 interoperability. State of the art POJO in Action book says

One challenge when using an in-memory database is ensuring that its schema is identical to the production database’s schema. This isn’t a problem if the ORM framework generates the database schema. However, if the production database schema is maintained separately, then its definition might not be compatible with the in-memory database. It could, for example, use vendor-specific data types and other features. In order to use an in-memory database, you will need to use a different schema definition or generate its schema from the ORM. In either case, there is no guarantee that the in-memory database has the same schema as the production database.

Although your question draws Hypersonic, H2 features includes

• Compatibility modes for IBM DB2, Apache Derby, HSQLDB, MS SQL Server, MySQL, Oracle, and PostgreSQL.

Maybe it can solve what you want. Try it.

Differents approachs can be used to populate the data needed to test. A useful guide is explained by XUnit Fixture Setup Patterns.

Other tools which can help you is

• Hibernate Tools reverse Engineering and Ant support

Answer 2

Basically, creating each entity programmatically (...) is too unwieldy given the data model and the populate.sql script we already have written (and is executed on DB2 for running our JBoss-hosted web site locally) can't be used on Hypersonic!

If you want to reuse your SQL script, you could try H2 with the DB2 compatibility mode, as suggested by @Arthur. If it doesn't work, try JavaDB/Derby, which is DB2's language compatible and can also be used "in-memory".

But if the script is huge, I'm afraid tests will be pretty slow. In that case, using DbUnit and smaller dataset could be an alternative. Have a look at the built-in DBUnitSeamTest and Functional testing with Seam, DBUnit, and TestNG.

And if you go the DbUnit way, you could use a tool like databene benerator to generate mock data and then dump them as DbUnit dataset (there is an eclipse plugin to ease this task).