Re: best practice for jpa/integration tests

2020-08-08 Thread Rick Hillegas
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  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.






best practice for jpa/integration tests

2020-08-06 Thread 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  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.