Hi,

I am working on a new datastore provider based on NeoEmf. My entity classes are generated and I can not (can, but probably too much work) modify the generation templates in order to add JPA annotations to them. As a result, I would like to use xxx-orm.xml mappings to describe my entities.

I am trying to test this by extending the OgmTestCase (and thus using OgmTestRunner). It seems that the current implementation does not scan the test/resources folder to find persistence.xml files. As a result if I remove the hiberante.properties file and use a persistence.xml file the tests fail.

I am getting an exception:


Which indicates that the test is not loading my datastore provider (btw, why is infinispan the default?) . It works when using the hiberante.properties.

Is there any way I can instruct the test case to use the properties.xml file to load the database/entities configuration?

My current digging suggests that I would ahve to modify (extend) the OgmTestRunner and the ogm.utils.TestHelper in order to
change how the SessionFactory is craeted and add the orm.xml mappings programatically (using addResource). Probably by using a new annotation @TestMappings so that the test case can provide a list of mapping files that should be added to the session factory.

Thanks!

Can you try with `OgmJpaTestCase`? It will use a different runner (OgmJpaTestRunner) that seems suited for what you are looking for.

That's the implementation we use when we want to test bwith JPA, OgmTestCase is for when we want to test the HIbernate Session.

We also have a JUnit rule to select a specific persistence XML file. You can check JPAJTATest for an example:



Historyically, Hibernate OGM was born has a mapper for Infinispan and I think that's the reason is still set as a default.

Thanks, that seems exactly what I need!

On a realted note, what is the approach to testing?

I find that each datastore follows it own set of tests, that is some use the Bookmark entity to test type mappings, others not. Some create an initial dabase some dont... I was hoping to follow the lead of the exsiting datastores, but frankly I am lost on what is expected to be tested.

Any pointes/links to information on what you expect/need from a datastore, test wise?

Cheers,

In core there are several test under the package: org.hibernate.ogm.backendtck
These tests are executed by default for each dialect. Every dialects may have additional tests that are run only on that particular dialect, it depends what we are testing and when we were working on it.

For example, in Neo4j we use native cypher queries to make that the content of the db is exactly the one we expect after some operations.
Sometimes, we re-used the same entity model in different tests, this is something taht we tend to avoid now and we prefer if each test uses it's own model (unless the tests are related somehow).

The reason for having different approaches is that every datastore is different, for example if you have an embedded or in memory datastore is very easy to start it up at the beginning of the test create the database and then destroy everything. Some other datastores don't have an embedded or in emory version and therefore we prefer to start them before the build and then execute the tests on them. Usually we dopr the database or delete everything after each test using the method in TestHelper'#dropSchemaAndDatabase. In short, it dependes what you can do with the datastore you are working with.

In general we expect that the dialect can pass most of the tests in the backendtck package, it means it should be able to execute CRUD operations on entities and associations with Id generation. We also expect some documentation describing the mapping (tests would be ideal). These requirement might change depedeing on the datastore.

Being able to convert HQL queries is not that important in the beginning.

There are other things that can be added but it usually varies from datastore to datastore.

I think the thing to keep in mind is that we expect to have documentation, tests a build that passes and clean code.

I hope this help.