How transactions in integraton tests work

When creating integraton tests it is essential to understand how Hybris manages o emulates transactions inside tests.

The preferred superclass for integration tests is ServicelayerTransactionalTest which starts a database transaction (if they are supported by the database engine) at the beginning of your test and makes a rollback when it finishes. This ensures that any change made in your test will be lost and it won't affect the next tests.

If your integration test is old, it may inherited from ServicelayerTest, ServicelayerBaseTest or HybrisJUnit4Test (all the superclasses of ServicelayerTransactionalTest). In this case, Hybris uses a proprietary mechanism implemented by the test run ItemCreationListener. This listener saves all the new models in a collection and it remove them from the database when your test finishes. Updates to existing models aren't rollbacked. This means that your old test may leave your database in a different state when it finishes and this may affect other tests.

In some special occasions you need to test without transactions like checking the use of the cache by your code. In this case, you have create a test class which doesn't inherited from HybrisJUnit4Test or any of its subclasses. This class turns on the ItemCreationListener and there is no way to override the value of the RunListeners annotation in any subclass.

Due to this, your test class must define what runner and listener to use:

@@RunWith(HybrisJUnit4ClassRunner.class)
@RunListeners(
        { LogRunListener.class, PlatformRunListener.class })
public class CacheManagementBeforeUpdateTest extends AbstractResourceAutowiringTest {
  (...)
}

–Based on Hybris 6.4 and 4.8