ebXML Persistence Test Suite

author: Heikki Doeleman

This page describes the automated tests for the Persistence Layer to the ebXML Object Model.

---

Persistence Layer Test Suite

The unit tests for the persistence layer create the database through ​Hibernate and then insert data into it, again using Hibernate. The resulting state of the database is verified by executing ​HQL queries. Where applicable, polymorphic HQL queries are tested as well.

The tests use the well-known unit testing framework ​Junit. Although developed against a local ​MySQL database, the tests are currently being remodeled such that they use an embedded ​McKoi database server; this removes the dependency of the test suite on a pre-installed external database server. Some peculiarities of McKoi are being accommodated, for instance it chokes if you try to create a table called "user". This last point is addressed by invoking an ​ImprovedNamingStrategy on the Hibernate configuration which causes all table names to be automatically prefixed by "RIM_".

Example

An example of a test case verifying that a RegistryObject is stored, both by querying on RegistryObject and polymorphically on its base class Identifiable, is this:

	public void testPersistingRegistryObject(){
		
		// create transient object
		RegistryObject transientRegistryObject = RegistryObjectFactory.createRegistryObject();
		URN businessKey = transientRegistryObject.getId();

		// make transient object persistent
		Transaction tx = hibernateSession.beginTransaction(); 
		hibernateSession.saveOrUpdate(transientRegistryObject);
		tx.commit(); 			 
		
		// verify database state
		Query registryObjectQuery = hibernateSession.createQuery("from RegistryObject o where o.id = '" + businessKey + "'");			  
		List<RegistryObject> registryObjectResult = registryObjectQuery.list();
		RegistryObject persistentRegistryObject = registryObjectResult.get(0);
		assertEquals(transientRegistryObject, persistentRegistryObject);

		// verify database state using a polymorphic query
		Query identifiableQuery = hibernateSession.createQuery("from Identifiable o where o.id = '" + businessKey + "'");			  
		List<Identifiable> identifiableResult = identifiableQuery.list();
		Identifiable identifiable = identifiableResult.get(0);
		assertEquals(transientRegistryObject, identifiable);
	}

This test unfortunately cannot run on a McKoi database. It seems McKoi does ​not support the SQL operator UNION, only UNION ALL. Hibernate however is under the hood issuing SQL queries containing UNION -- this is a result of the <union-subclass> mapping strategy we have chosen to model OO inheritance. This causes McKoi to raise the descriptive error "ERROR: PENDING" and the test case fails.

So for McKoi a test case could use an SQL query, rather than an HQL query. This means the test case is less interesting because we're back to writing SQL, we must explicitly apply our ImprovedNamingStrategy in the SQL, and we cannot do polymorphic queries. So much for DBMS vendor independence :-( The test case below is an example that can run in McKoi.

	public void testPersistingRegistryObject(){
		
		// create transient object
		RegistryObject transientRegistryObject = RegistryObjectFactory.createRegistryObject();
		URN businessKey = transientRegistryObject.getId();

		// make transient object persistent
		Transaction tx = hibernateSession.beginTransaction(); 
		hibernateSession.saveOrUpdate(transientRegistryObject);
		tx.commit(); 	
		
		// verify database state using SQL
		Query registryObjectQuery = hibernateSession.createSQLQuery("select ID from RIM_REGISTRY_OBJECT where ID='" + businessKey + "'");
		List<String> result = registryObjectQuery.list();
		URN persistentRegistryObjectId = new URN(result.get(0));
		assertEquals(persistentRegistryObjectId, businessKey);
	}

The tests in the test suite are being remodeled such that by default they will run McKoi-friendly test cases, which can be overruled by a setting to run the HQL-based test cases.