Problem: When an integration test fails, it often not delete his test data (I mostly use DbUnit for that). Because of this, other tests will also fail (for example because they want to delete their test data, but it is referenced by data which shouldn't exist at this point --> test will fail).
Is there a possibility that Jenkins use for every single test or for every Java test class a fresh/clean database with the init data (I don't need a complete empty database), that my integration tests are more independent?
Use a spring.jpa.hibernate.ddl-auto=create-drop property or annotate your test class with #Transactional.
Related
I have a #Service class where i'm caching some table data. I don't want those queries to run while building mvn install. Is there a way to ignore the file while building and it only execute when i start the server ?
It's a spring-boot application.
Here is background of my issue. I have initialized the spring boot app from http://start.spring.io/ site, which actually adds dummy application test file with SpringBootTest annotation and default contextLoads() with Test annotation, with an intention to initialize and execute all test cases, which needs to initialize and execute all code base. In my opinion this is not required, as we can have respective Test classes per controller/manager, which will give more controlled environment to hook up your Test setups and executions.
I have removed the default application Test file and included respective test classes for code coverage and quality. This way my beans are not executed at server startup time rather build time.
I have problem with unit tests for persistance stuff written in spring data jpa.
For particular repositories I have a unit tests to be sure that everything works correctly. Also I have a integration tests. Each tests are passed when I run it for particular test classes. But when i run a whole package of tests I got a lot of faliures because I have records inserted into DB from previous tests.
Of course in each test classes I can add #After method to clean each data but I would like to ask that it posible to clean all data from DB before run tests from particular test classes without adding #After method?
Best Regards.
Use Spring's transactional test support to ensure that database changes are rolled back after each test:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/testing.html#testcontext-tx
One common issue in tests that access a real database is their effect
on the state of the persistence store. Even when you’re using a
development database, changes to the state may affect future tests.
Also, many operations — such as inserting or modifying persistent
data — cannot be performed (or verified) outside a transaction.
The TestContext framework addresses this issue. By default, the
framework will create and roll back a transaction for each test.
How can we load data which will be used by the JUNIT tests and at the end roll back using spring unit testing?
You can have your test class extend something like:
http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/test/context/junit4/AbstractTransactionalJUnit4SpringContextTests.html
See sections 9.3.2.3 and 9.3.5.4 the Spring documentation for further info:
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/testing.html#testing-tx
You can use this in conjunction with something like DBUnit to populate your database with known data.
I would like to create some data in #BeforeClass and use them in my #Test method.
After all tests are finished (failed or succeeded), I would like to rollback the data.
Can this be achieved using the annotations #BeforeClass, #Transactional, without having to clean up the data explicitly?
We had a similar problem here. Our solution was to give each test class an embedded H2 database (just takes a couple of seconds to setup the first one; after that, it's not really noticeable anymore).
That allowed us to load any kind of test data into the database, no need to clean that up after all tests have run.
Each test still gets its own transaction, so after each individual test, the per-class database is rolled back to the original state.
To debug tests, we would annotate the individual test with #Transactional(rollback=false), so we could look at the database with an SQL tool.
Another test would examine all tests classes, looking for this annotation to make sure no one accidentally commits it.
I have two separate integration test files, each with their own context configuration files (XML). When I incorporate both of them into the build cycle, I run into problems, but if I put the #Ignore annotation on one of them, everything works fine.
The specific problem I'm having is with persistence; when both integration tests are in the build cycle, one of my tests does not persist objects correctly to the database. I don't get errors, and it says it's persisting, and Hibernate outputs the log entry saying it is inserting, but when I check the database table, nothing is there. Then when I run the test by itself (#Ignore on the other test), it writes to the database table as it should.
Does it matter that I'm using some of the same variable names in the context config files? For example, both files have a transaction manager called "deviceTxManager". I figured this was OK since they are completely separate configuration files used for different tests.
Should I be somehow "purging" the context of the previous integration test before running the next test?
The culprit was in my persistence.xml file. I am using
<property name="hibernate.hbm2ddl.auto" value="create" />
which apparently is used separately by each separate integration test class. So, the second integration test was recreating the database schema, thus purging the database changes made by the preceding integration test.
I thought persistence.xml was only accessed once before all integration tests are run, but apparently I was wrong; it is accessed separately by each separate integration test class and the database is cleared and recreated for each test class.