Can Mocktio mock a persistence provider, so that jenkins (or other pipeline tools) can execute JUnit tests without a database?

Question

So I wrote JUnit tests, including Mockito, for an API that directly uses DAOs. The mocking of the EntityManager and EntityTransaction is no problem and the tests are running fine on a machine, where the persistence provider can connect to the database. (EclipseLink is used)

Jenkins however, which is also running these tests, has no access to the database in question. Everytime Jenkins executes the tests I get:

No Persistence provider for EntityManager named XYZ

I do understand that this occurs due to the fact that jenkins can not establish a real connection to the database. This behavior is intentional and should not change.

My question therefore is: is it possible to mock (with Mockito?), or in antoher way fake, the connection so that a fake EntityManagerFactory / persistence provider can be used?

Are you mocking the Entity Manager while sill connecting to the real database? Does it mean that you don't actually run queries against the database while testing but build the persistence unit anyway? — briadeus, Nov 14 '18 at 13:13
That describes the problem quite well. The unit that is testes uses DAOs. For this the constructor of the API connects to the database and instantiates an EntityManager. — Felix, Nov 14 '18 at 15:30
You have two options: 1) refactor your dependencies and use simple unit tests to test what should be tested (e.g. no database access) 2) configure some in memory database (like Derby), fill it with test data, initialize PU and run tests against it (if this is what is supposed to be tested). — briadeus, Nov 14 '18 at 17:48
I think I'm going for the latter, since the API design is approved the way it is right now. Thanks for the hints. — Felix, Nov 15 '18 at 09:07
We are using the spring container in couple of projects, you can find a simple example here: https://www.logicbig.com/tutorials/spring-framework/spring-core/integration-testing.html — briadeus, Nov 15 '18 at 09:46

score 1 · Accepted Answer · answered Nov 16 '18 at 08:29

A way to test the closed API without a real database access is to build and fill & tear-down an in-memory database for tests. A simple setup with Spring & Derby for Eclipselink would be

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.transaction.TransactionConfiguration;
import javax.persistence.EntityManagerFactory;
import javax.persistence.PersistenceUnit;

@ContextConfiguration(classes = AppConfig.class)
@TransactionConfiguration(defaultRollback = false)
public abstract class AbstractContainer {

@PersistenceUnit(unitName = "PERSISTENT_UNIT_NAME")
protected EntityManagerFactory factory;

@Autowired
protected ApplicationContext applicationContext;

}

and

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.datasource.DriverManagerDataSource;
import org.springframework.orm.jpa.JpaVendorAdapter;
import org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean;
import org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter;
import java.util.Properties;
import javax.sql.DataSource;

@Configuration
public class AppConfig {

@Bean
public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
LocalContainerEntityManagerFactoryBean em =
    new LocalContainerEntityManagerFactoryBean();
em.setDataSource(dataSource());
em.setPersistenceUnitName("PERSISTENT_UNIT_NAME");
em.setPackagesToScan(new String[] { "package.name.to.scan" });

JpaVendorAdapter vendorAdapter = new EclipseLinkJpaVendorAdapter();

em.setJpaVendorAdapter(vendorAdapter);
// here some additional properties for the PU
em.setJpaProperties(additionalProperties());

return em;
}

Properties additionalProperties() {
Properties properties = new Properties();

properties.setProperty("eclipselink.weaving", "false");
properties.setProperty("eclipselink.query-results-cache", "false");
properties.setProperty("eclipselink.cache.shared.default", "false");

properties.setProperty("javax.persistence.jdbc.driver",
    "org.apache.derby.jdbc.EmbeddedDriver");
properties.setProperty("javax.persistence.jdbc.url",
    "jdbc:derby:memory:NAME;create=true");

properties.setProperty("javax.persistence.jdbc.url", "jdbc:derby:PATH");
properties.setProperty("javax.persistence.jdbc.user", "");
properties.setProperty("javax.persistence.jdbc.password", "");

properties.setProperty("javax.persistence.sql-load-script-source",
    "META-INF/sql/createDB.sql");
properties.setProperty("eclipselink.deploy-on-startup", "true");
properties.setProperty("eclipselink.target-database", "Derby");

return properties;
}

public DataSource dataSource() {
DriverManagerDataSource dataSource = new DriverManagerDataSource();
try {
  Class.forName("org.eclipse.persistence.jpa.PersistenceProvider");
  Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
} catch (ClassNotFoundException cnfe) {
  cnfe.printStackTrace();
} catch (InstantiationException inste) {
  inste.printStackTrace();
} catch (IllegalAccessException iace) {
  iace.printStackTrace();
}

dataSource.setDriverClassName("org.apache.derby.jdbc.EmbeddedDriver");
dataSource.setUrl("jdbc:derby:memory:NAME;create=true");

dataSource.setUsername("");
dataSource.setPassword("");

return dataSource;
}

}

The SQL Script lies under test/resources/META-INF/sql/createDB.sql.
Finally your Test Class extends the Abstract Container using the SpringJUnit4ClassRunner.class Runner and starts a local transaction.

@RunWith(SpringJUnit4ClassRunner.class)
public class DAOTest extends AbstractContainer {

@Test
public void testDAO() {

EntityManager em = factory.createEntityManager();
em.getTransaction().begin();
}
}

The persistence unit for tests is per default expected under test/resources/META-INF/.

Dependencies using Maven

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>[4.1.7.RELEASE]</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-orm</artifactId>
        <version>[4.1.7.RELEASE]</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-test</artifactId>
        <version>[4.1.7.RELEASE]</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-mock</artifactId>
        <version>[2.0.8]</version>
        <scope>test</scope>
    </dependency>   
    <dependency>
        <groupId>org.apache.derby</groupId>
        <artifactId>derby</artifactId>
        <version>10.11.1.1</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.derby</groupId>
        <artifactId>derby</artifactId>
        <version>10.11.1.1</version>
        <scope>test</scope>
    </dependency>

Can Mocktio mock a persistence provider, so that jenkins (or other pipeline tools) can execute JUnit tests without a database?

1 Answers1