How can I persist entities during a SpringBootTest integration test - java

I am writing an integration test for a SpringBoot 2 RestController. I want to test 404 behaviour and creation of entities. However, when I try to create entities and persist them before or during a test, they are not persisted in the SpringBoot context. By that I mean they are visible in the test context (during debugging of the test) but not for the Controller (ie it does not find them and my tests fail). What am I doing wrong?
How can I persist entities and flush the context during a test so that code that is called during an integration test sees them? I don't want to use a #before annotation to populate a database because I want to do it in my #test methods.
Here is my code. Thanks
#RunWith(SpringRunner.class)
#Transactional
#SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class InvoiceControlllerIT extends GenericControllerIT {
#Autowired
EntityManager entityManager;
#Test
#Transactional
public void cascadesChildEntityAssociationOnCreate() throws IOException {
assertThat(invoicerRepository.count(), equalTo(0L));
assertThat(invoiceRepository.count(), equalTo(0L));
assertThat(invoiceeRepository.count(), equalTo(0L));
// create an invoicee
Invoicee savedInvoicee = invoiceeRepository.save(new Invoicee());
assertThat(invoiceeRepository.count(), equalTo(1L));
// create an invoicer
Invoicer savedInvoicer = invoicerRepository.save(new Invoicer());
assertThat(invoicerRepository.count(), equalTo(1L));
// THIS IS THE PROBLEM, FLUSHING DURING THE TEST DOES NOT EFFECT THE CONTROLLERS ABILITY TO SEE THE NEWLY CREATED ENTITIES
entityManager.flush();
// create input
InvoiceInputDto inputDto = InvoiceInputDto
.builder()
.invoicee(savedInvoicee.getId())
.invoicer(savedInvoicer.getId())
.name("test-name")
.build();
// make call
ResponseEntity<InvoiceDto> response = template.postForEntity(url("/invoices", TOKEN), inputDto, InvoiceDto.class);
assertThat(response.getStatusCode(), equalTo(HttpStatus.CREATED));
assertThat(response.getBody().getName(), equalTo(inputDto.getName()));
// check associations
assertThat(invoiceeRepository.findById(savedInvoicee.getId()).get().getInvoices(), hasSize(1));
}
}

According to the docs:
If your test is #Transactional, it rolls back the transaction at the
end of each test method by default. However, as using this arrangement
with either RANDOM_PORT or DEFINED_PORT implicitly provides a real
servlet environment, the HTTP client and server run in separate
threads and, thus, in separate transactions. Any transaction initiated
on the server does not roll back in this case
(source: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html#boot-features-testing-spring-boot-applications)
Since the test transaction is separate from the HTTP server transaction, the controller won't see changes made from within the test method until the test transaction is actually committed. Conversely, you won't be able to roll back changes made as a result to the server call.
You will seriously make your life easier by providing a mock implementation for whatever service/repository your controller uses. Alternatively, you could use a tool like DBUnit to setup and tear down the database around each test case.

This worked for me:
#Inject
private EntityManagerFactory entityManagerFactory;
#BeforeEach
void setUp() {
EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
entityManager.persist(someEntity());
entityManager.getTransaction().commit();
}

Related

How to save entities along with their related entities in spring boot integration testing?

I have an integration test on a endpoint of creating a user with its related entities. It turns out that the related entities were not persisted with the user entity.
However, it is working fine when running the normal spring boot application. Is it possible to achieve this during testing?
This is the log when running the integration test of the endpoint
And this is the log when calling from Postman to the normal application
as you can notice the roles are not inserted to the rel_mi_user__mi_user_role table during integration testing.
The setup source code for the integration test is shown below
#Autowired
private PasswordEncoder passwordEncoder;
#Autowired
private MockMvc mockMvc;
#Autowired
private MiMiUserRepository miMiUserRepository;
private static Logger log = LoggerFactory.getLogger(MiMiUserResourceIT.class);
#Test
#Transactional
void testRegisterBackOfficeUser() throws Exception {
MiMiUserRegistrationDTO userRegistrationDTO = new MiMiUserRegistrationDTO();
userRegistrationDTO.setPassword("test12345");
userRegistrationDTO.setEmail("john#gmail.com");
userRegistrationDTO.setContactNo("0188991122");
userRegistrationDTO.setUserRoles(List.of("BACKOFFICE"));
MiMiUserProfileRegistrationDTO profile = new MiMiUserProfileRegistrationDTO();
profile.setSalutation("Mr");
profile.setFirstName("John");
profile.setLastName("Lee");
userRegistrationDTO.setProfile(profile);
mockMvc
.perform(
post("/v1/p/user/register/back-office")
.contentType(MediaType.APPLICATION_JSON)
.content(TestUtil.convertObjectToJsonBytes(userRegistrationDTO))
)
.andExpect(status().isCreated());
MiUser u = miMiUserRepository.findOneWithMiUserRolesByEmailIgnoreCase(userRegistrationDTO.getEmail()).get();
assertThat(u.getUserStatus()).isEqualTo(UserStatus.NEW);
}
I guess it has to do with the fact that your whole test is annotated with #Transactional. When you annotate your test method with #Transactional, everything that happens during that test happens within one single transaction. As you might know, changes are only flushed to the database at the end of a transaction unless you call the flush method manually which is generally discouraged unless you know what you are doing because you interfere with your JPA provider's flushing optimization.
Only when the changes are flushed to the DB, auto-generated properties like an ID is set on your entity and DB constraints are evaluated. Yes, you're reading it right, you might even violate a DB constraint within your test without the test failing!
Here you can find more reasons why you should not annotate your tests with #Transactional.
If you need to save several entities in the arrange part of your test, you can autowire the Spring TransactionTemplate and create all your entities within a manual transaction. The same might apply to asserts where you load an entity from the DB and want to evaluate a lazy-loaded collection of said entity. As far as I can tell, neither of said scenarios apply to your test, just try omitting the #Transactional and your test should work.
Side note: if you write #DataJpaTests you always need to call the saveAndFlush method of the repository instead of the save method because #DataJpaTests are always transactional.

Spring testing DB rollback

I am #new to spring and faced some problem while running some tests. I have a few test-classes with the following code which should rollback my (in memory h2) database:
#Autowired
PlatformTransactionManager txm;
TransactionStatus txstatus;
#BeforeEach
public void setupDB() {
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
txstatus = txm.getTransaction(def);
assumeTrue(txstatus.isNewTransaction());
txstatus.setRollbackOnly();
}
#AfterEach
public void rollback() {
txm.rollback(txstatus);
}
My problem is, that if one test class has finished, I get a JdbcSQLIntegrityConstraintViolationException (Unique index or primary key violation:..), because my Database is not rollbacked accordingly and Insert statements are executed again, because the database didnt get cleared. Does anyone has a tip how to fix that? Is there a way to rollback the inserts or not to do the inserts after they have been done ones?
You can just annotate your test class with
#Transactional
and Spring will handle everything (which means each test will run in its own transaction which will be rolled back after).
You can also use
#DirtiesContext(classMode = ClassMode.BEFORE_EACH_TEST_METHOD)
but this is heavy because the whole Spring context must be recreated.
A simple solution is to use the DirtiesContext annotation. This annotation has several options. You can use the below line in your test class:
#DirtiesContext(classMode = ClassMode.BEFORE_CLASS)
The context will be removed and recreated before the test class execution.

JPA 2.0 disable session cache for unit tests

I am writing unit test for my services e. g. :
#Test
#Rollback(value = true)
public void testMethod()
{
// insert test data
myService.Method(); // read/write from DB
// asserts go here
}
While application running, a new transaction is created every time method A entered. But during the unit test execution - when test testMethod entered. So method A doesn't create new one.
For proper testing I need to clear cache before every call to service inside test.I don't want to write Session.clear() before any call to service in each unit test. What is the best best practices here?
The EntityManager has a method clear() that will drop all persistence context:
Clear the persistence context, causing all managed entities to become detached. Changes made to entities that have not been flushed to the database will not be persisted.
If you call a query right after that method it will come directly from the database. Not from a cache.
If you want to run this before every test, consider using a JUnit #Rule by subclassing ExternalResource and running the method on every before() or after(). You can reuse that in al you database tests.
There are several way:
Evict Caches Manually
#Autowired private CacheManager cacheManager;
public void evictAllCaches(){
for(String name : cacheManager.getCacheNames()){
cacheManager.getCache(name).clear();
}
}
Turning Off Cache for Integration Test Profile
for Spring Boot: spring.cache.type=NONE
or
/** * Disabling cache for integration test */
#Bean public CacheManager cacheManager() {
return new NoOpCacheManager();
}
Use #DirtiesContext
#DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
class CacheAffectedTest { ...
In this case Spring context re-created after every test and test's time in my measure tripling.
For developing Spring Boot Dev Tools turns caching off automatically during the development phase.
See Spring Cache and Integration Testing and A Quick Guide to #DirtiesContext

How to flush data into db inside active spring transaction?

I want to test hibernate session's save() method using spring testing framework.
#Test method is :
#Test
#Transactional
public void testSave() {
User expected = createUser();
getGenericDao().currentSession().save(expected);
User actual = getUser(generatedId);
assertUsersEqual(expected,actual);
}
I want to flush user into database. I want my user to be in database after this method
getGenericDao().currentSession().save(expected);
Then I want to go to database using spring data framework and fetch this saved user by next line:
User actual = getUser(generatedId);
I tried to use hibernate flush method like:
currentSession().setFlushMode(MANUAL);
//do saving here
currentSession().flush();
It does not flush my user into database!
However if I don't make use of #Transactional spring annotation and save my user in programmatic spring transaction I achieve what I want. Unfortunately then user saved into db
is not rollbacked as there is no spring #Transactional. Therefore my test method changes the db and behaviour of subsequent test methods.
So I need to flush my user into db inside test method(not at the end) and at the end of test method rollback all changes to db.
UPDATE suggestion to prepare method as follows:
#Transactional
public void doSave(User user){
getGenericDao().currentSession().save(user);
}
And call doSave inside testSave is doing nothing. Still I have no user in db after executing this method. I set breakpoint and check my db from command-line.
UPDATE Thanks very much for response. The problem is that method flush() does not put my user into database.I tried Isolation.READ_UNCOMMITTED and it does not put my user into database. I can achieve what I want but only if I turn off spring transaction on #Test method and do saving in programmatic transaction. BUT then #Test method is not rolled back leaving saved user for subsequent #Test methods. Here #Test method to save user is not as dangerous as #Test method to delete user, because it is not rolled back. So there must spring transactional support for #Test method with which I can't anyway put my user(or delete) into db. Actually user is put(or deleted) into db only after #Test method ends and transaction for #Test method is comitted. So I want to save my User into db in the middle of #Test method and roll back it at the end of #Test method
Thank you!
Finally I stuck to the following solution:
First, my #Test methods are not running within spring #Transactional support. See this article to know how dangerous it may be. Next, instead of using #Repository beans inside #Test methods I autowire #Service beans which use #Transactional annotation.
The miracle is that #Test method like this
#Test
#Transactional(propagation = Propagation.NOT_SUPPORTED)
public void testSave() {
Answer created = createAnswer();
Long generatedId = answerService.save(created);
//at this moment answer is already in db
Answer actual=getAnswerById(generatedId);
... }
puts my Answer object into database (just after answerService.save(created);) and method getAnswerById goes to DB and extracts it to check if save was correct.
To eliminate changes made to database in #Test method I recreate database by JdbcTestUtils.executeSqlScript
Have a look here with warning about #Transactional tests (Spring Pitfalls: Transactional tests considered harmful). I've used #org.springframework.test.context.jdbc.Sql to re-populate DB in my service tests and #Transactional for controllers.
ConstraintViolationException for controller update test with invalid data have been thrown only when transaction is committed. So I've found 3 options:
2.1 Annotate test with #Commit or with #Transactional(propagation = Propagation.NEVER). Be aware of DB change.
2.2 Use TestTransaction
Code:
TestTransaction.flagForCommit();
TestTransaction.end();
2.3 Use TransactionTemplate
Code:
#Autowired
private PlatformTransactionManager platformTransactionManager;
#Test(expected = Exception.class)
public void testUpdate() throws Exception {
TransactionTemplate transactionTemplate = new TransactionTemplate(platformTransactionManager);
transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
String json = ...
transactionTemplate.execute(ts -> {
try {
mockMvc.perform(put(REST_URL + USER_ID)
.contentType(MediaType.APPLICATION_JSON)
.content(json))
.andExpect(status().isOk());
...
} catch (Exception e) {
e.printStackTrace();
}
return null;
});
You should also take care of the importedpackage :
in my case I imported
import javax.transaction.Transactional;
instead of
import org.springframework.transaction.annotation.Transactional;
If flush is not working then it very much depend on your database isolation level.
Isolation is one of the ACID properties of database, that defines how/when the changes made by one operation become visible to other concurrent operations.
I believe your isolation level is set to Read Committed or Repeatable Read.

JUnit tests always rollback the transactions

I'm running a simple JUnit test agains an application DAO. The problem is that I always get:
javax.persistence.RollbackException: Transaction marked as rollbackOnly
The JUnit test is:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath:com/my/app/context.xml"}
#TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = false)
#Transactional
public class PerformanceTest {
#Test
#Transactional(propagation= Propagation.REQUIRES_NEW)
#Rollback(false)
public void testMsisdnCreationPerformance() {
// Create a JPA entity
// Persist JPA entity
}
}
As you can see I'm declaring clearly not to rollback this method.
Does Spring JUnit support always sets rollback to true?
It should work, like you expect it, but may be you open another transaction within your class under test or you have an other feature/or bug somewhere.
Btw this annotations should be enougth:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath:com/my/app/context.xml"}
#Transactional
public class PerformanceTest {
#Test
#Rollback(false)
public void testMsisdnCreationPerformance() {
// Create a JPA entity
// Persist JPA entity
}
}
#See Spring Reference Chapter 9.3.5.4 Transaction management (or current version)
Just add annotation Rollback and set the flag to false.
#Test
#Rollback(false)
It is strange to desire a test that changes your database and keep the modification.
Tests are supposed to be orthogonal : no test depends on an other.
Moreover, tests are supposed to be independent of tests order, and even idempotent.
So either you want to change you data base in your setUp() method and rollback the change in your tearDown() method, either you want to setup a test database with some good values in it for tests.
Maybe I am missing something here but usually you should not want that.
From official Documentation:
By default, test transactions will be automatically rolled back after
completion of the test; however, transactional commit and rollback
behavior can be configured declaratively via the #Commit and #Rollback
annotations
https://docs.spring.io/spring/docs/current/spring-framework-reference/html/integration-testing.html#integration-testing-annotations
#Commit indicates that the transaction for a transactional test method
should be committed after the test method has completed. #Commit can
be used as a direct replacement for #Rollback(false) in order to more
explicitly convey the intent of the code.
I use Junit5, both commit and rollback(false) works with me.
#ExtendWith(SpringExtension.class)
#SpringBootTest
#Transactional
public class MyIntegrationTest {
#Test
#DisplayName("Spring Boot Will Rollback Data, " +
"Can Disable it By Add #Commit Or #Rollback(false) Annotation")
//#Commit
//#Rollback(false)
public void test() throws Exception {
//your test codes here...
}
I agree the Ralph's answer.
The Propagation.REQUIRES_NEW creates a new transaction and this probably does not match with the main transactional route in which the test is running.
In my simple experience the annotation #Transactional will properly work to define the transactional context in which every single test should run, delegating to this one the specific current Rollback clause (as shown by Ralph).
The Ralph's answer is useful and in the same time the Snicolas's answer concerns a particular case of managing context of tests.
The idempotence is fundamental for integration and automatic tests, but should be different ways to implements them.
The question is, which kind of methods do you have? And what behavior do theese methods have?
[...]
#Transactional
public class Test {
#Test
#Rollback(false)
public void test() {
[...]
Is the simple, question-coherent way :)
add #Rollback on your Test class-level
add #Transactional(value = "your_ManagerName",rollbackFor = Exception.class) on your test method

Categories