opentable/otj-pg-embedded

JUnit5 extensions too inflexible

jordanglassman opened this issue · 2 comments

While migrating a test to using com.opentable.db.postgres.junit5.SingleInstancePostgresExtension, I discovered that since it uses beforeTestExecution and afterTestExecution, any DB configuration performed in a @BeforeAll method can't be seen by PG.

For example:

public class SomeTest {
    @RegisterExtension
    public static SingleInstancePostgresExtension pg = EmbeddedPostgresExtension.singleInstance().customize(builder -> {
        // do some customizations that will be applied after @BeforeAll and @BeforeEach
    });

    @BeforeAll
    public static void setUpClas() {
        // all of this will fail since PG hasn't been instantiated yet
        PGSimpleDataSource dataSource = new PGSimpleDataSource();
        dataSource.setURL(String.format("jdbc:postgresql://localhost"));
        jdbi = Jdbi.create(dataSource);
        Flyway flyway = Flyway.configure();
        flyway.migrate();
    }

    @BeforeEach
    public void setUp() throws Exception {
        // all of this will fail since PG hasn't been instantiated yet
        PGSimpleDataSource dataSource = new PGSimpleDataSource();
        dataSource.setURL(String.format("jdbc:postgresql://localhost"));
        jdbi = Jdbi.create(dataSource);
        Flyway flyway = Flyway.configure();
        flyway.migrate();
    }

    @Test
    public void createUser() throws Exception {
        // could do DB config here, but would need to manually run it before every test
    }
}

Am I missing a better way to use this? Perhaps beforeAll/afterAll would be better callback choices?

My workaround is to just use a local copy of SingleInstancePostgresExtension that uses beforeAll/afterAll instead of beforeTestExecution/afterTestExecution.

I'm not really strong on Junit5 yet - we are just transitioning. This was a PR provided (which was awesome). If you have another PR to improve this, by all means it would be welcomed!

qutax commented

@mikebell90 I created a pull request that fixes this issue: #138