best practice for jpa/integration tests

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

best practice for jpa/integration tests

Marco Ferretti
Hi all, 

I have been struggling to find a decent solution for my (low priority) issue.

I have a situation where I want to do an integration test for an application based on CDI/EJB. I have my persistence.xml configured with "jdbc:derby :memory" and I have the database creation/drop scripts that work when running from SQL console. 
My unit tests are set-up so that each time a single is run the database gets to dropped and re-created. The problem is that each time a test unit (file) is run, it adds to the error logs as it tries to drop the database before any object is actually created. 
The issue seems to be that the standard JPA way of doing such things (from a script) is to run the drop(s) before the create(s) and, for as much as I have searched, I haven't found a way to change this behaviour by acting on the configuration.
As far as I know, Derby does not support "DROP <whatever> IF EXISTS" thus my drop-schema script fails with a bunch of errors the first time a test unit is run. 
Since we HAVE to be agnostic towards the actual JPA implementation, I was wondering if you have any suggestion as to how I shall circumvent such an annoying issue.

Thanks is advance for any hints you can provide.


p.s.: I know I can create the database in the @BeforeClass and drop it in the @AfterClass, I was looking to work "outside" the application's code-base.



Marco F.
Reply | Threaded
Open this post in threaded view
|

Re: best practice for jpa/integration tests

Rick Hillegas-3
Can't you to tell the object/relational mapping layer or the test
framework to swallow certain errors? Note that an in-memory database can
be dropped and recreated for each test case if you really need a blank
slate.

On 8/6/20 3:39 AM, Marco Ferretti wrote:

> Hi all,
>
> I have been struggling to find a decent solution for my (low priority) issue.
> I have a situation where I want to do an integration test for an application based on CDI/EJB. I have my persistence.xml configured with "jdbc:derby :memory" and I have the database creation/drop scripts that work when running from SQL console.
> My unit tests are set-up so that each time a single is run the database gets to dropped and re-created. The problem is that each time a test unit (file) is run, it adds to the error logs as it tries to drop the database before any object is actually created.
> The issue seems to be that the standard JPA way of doing such things (from a script) is to run the drop(s) before the create(s) and, for as much as I have searched, I haven't found a way to change this behaviour by acting on the configuration.
> As far as I know, Derby does not support "DROP <whatever> IF EXISTS" thus my drop-schema script fails with a bunch of errors the first time a test unit is run.
> Since we HAVE to be agnostic towards the actual JPA implementation, I was wondering if you have any suggestion as to how I shall circumvent such an annoying issue.
>
> Thanks is advance for any hints you can provide.
>
> p.s.: I know I can create the database in the @BeforeClass and drop it in the @AfterClass, I was looking to work "outside" the application's code-base.
>
> Marco F.
>
>