22

My application uses Spring-Boot 1.4.1.RELEASE and the configuration of my datasource is as follows;

spring:
  datasource:
    url: ***
    username: ***
    password: ***
    driver-class-name: oracle.jdbc.driver.OracleDriver
    initial-size: 1
    max-active: 100
    max-idle: 30
    min-idle: 1
    max-wait: 0
    pool-prepared-statements: true
    max-open-prepared-statements: 3

The problem is that the last case of my integration testing if it contains a @Sql setup logic in it, fails to commit the last setup SQL. The trouble happens rarely due to the reordering of the cases, and the fact that there is only a handful cases with setup logic to prepare DB. There is no configuration but the one for the OracleDB, and that is in the ConfigClass.

@SpringBootTest(classes = ConfigClass.class)
public class EtcTest {

    @After
    public void teardown() {
        // teardwon X, Y, & Z
    }

    @Test
    @Sql("setupX.sql")
    @Sql("setupY.sql")
    @Sql("setupZ.sql")
    public void get_fromDb() {
        List<Etc> list = buildExpectedList();
        Obj expected = buildExpected();
        Obj actual = getCallToAPI();

        assertThat(rs.getX()).isEqualTo(expected.getX());
        assertThat(rs.getY()).isEqualTo(expected.getY());
        assertThat(rs.getZ()).containsAll(list);
    }
}

The trouble, for example in the above case if it were the last integration case, that it fails to commit the last SQL in the @Sql annotations, namely SetupZ.sql, but the data is not completely missing, it inserts the primary key, and sometimes columnA, or columnB, it is as if something is really wrong here.

Would the presence or absence of some configuration cause this? If not what would be the reason?

buræquete
  • 12,943
  • 4
  • 34
  • 69
  • 4
    If you're using auto-configuration, you should read [the release note](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Release-Notes) when you upgrade, and in particular [this section](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Release-Notes#datasource-binding). All the connection pool specific settings have moved to dedicated namespace. Review your configuration. – Stephane Nicoll Mar 03 '17 at 12:31
  • @StephaneNicoll I have been using the same version, the only change was that I've added some setup & teardown methods that are annotated with junit's before and after annotations. I've had a successful build last time when somehow the build put a non-db related test at the end, now I am again getting same non-commit issue with the last case again. – buræquete Mar 08 '17 at 05:52
  • 2
    For Oracle 9i onwards you should use `oracle.jdbc.OracleDriver` rather than `oracle.jdbc.driver.OracleDriver` as Oracle have stated that `oracle.jdbc.driver.OracleDriver` is deprecated . – Robert Hume Mar 09 '17 at 05:25
  • Are you using java 8 ? – OTM May 03 '17 at 14:48
  • 1
    Have you tried to make your test `@Transactional` ?? And if possible introduce `@Before` method with same `@SQL` annotations. – Ilya Dyoshin May 05 '17 at 20:40

4 Answers4

2

You can work with @Transactional tests. This allow you to run the test check the result and get BD rolled back to pre-test state.

Reference http://docs.spring.io/spring/docs/4.3.11.RELEASE/spring-framework-reference/htmlsingle#testcontext-tx-enabling-transactions

Aleh Maksimovich
  • 2,336
  • 5
  • 18
1

Hi for test classes instead of actual database you can go with In-Memory databases like DB2,derby and h2. it provides the solution for your trouble.

for Code example you can find below URL Spring data jpa repository In-memory test case

Community
  • 1
  • 1
AdamIJK
  • 529
  • 2
  • 10
  • 21
1

You would try use JPA for persisting. The following settings would be available:

spring.jpa.show-sql=true

Then you could see what went wrong.

gofr1
  • 15,066
  • 11
  • 38
  • 47
0

This was due to some conflicting libraries within both JUnit & Spring/Hibernate. After updating to the latest Spring & Junit version & updating to Java8 the issue is gone.

buræquete
  • 12,943
  • 4
  • 34
  • 69