getMappedPort/getJdbcUrl should fail fast when requested ports have not been mapped about testcontainers-java

[ldcasillas-progreso]

I've just been looking at this line of code, and I have some thoughts.

First of all, if the getMappedPort() call returns a null then the URL generation code needs to fail fast instead of composing a bogus JDBC URL. I think this is the bare minimum for closing this ticket—if my test is failing because a port did not get mapped, I should get an error message saying that, not one that suggests that a JDBC driver was not found.

Second: since the getMappedPort() method is in the GenericContainer class, I can't help but think that this failure mode affects more than just the PostgreSQLContainer class. Perhaps the code would benefit from being refactored so that:

• getMappedPort() returns int instead of Integer;
• getMappedPort() throws an exception when a caller requests a port that hasn't been mapped;
• Callers that are checking whether a port has been mapped or not must use some other method than checking getMappedPort() and testing the result for null.

This is just a suggestion, though—not my code!

[rnorth]

Hi Luca
Sorry you've had a problem, and thanks for the detailed feedback. I definitely agree that this code needs to have some more resilience. I think that:

• Yes, getJdbcUrl() needs to assert that it's not getting bad data and fail-fast
• Probably getMappedPort() should, as you suggest, throw an exception if you ask it for an unmapped port. I can't (yet) think of a scenario where this would be a bad thing, but will have a play.

These are really useful suggestions, so thanks.

Going back to your underlying problem, I'm surprised that you're ending up with a bad port mapping at all. The only thing that I can think of is that your makeDataSource() method is being called before the container is created. Is this possible? Do the logs show the container starting up before your method is called?

Just to be sure that it's not use of @ClassRule I've tried modifying one of the tests. It seems to work OK if run as shown below. Would you be able to try this, or something similar, to try and narrow down where the problem lies?

public class SimplePostgreSQLTest {

    @ClassRule
    public static PostgreSQLContainer postgres = new PostgreSQLContainer();

    @Test
    public void testSimple() throws SQLException {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(postgres.getJdbcUrl());
        hikariConfig.setUsername(postgres.getUsername());
        hikariConfig.setPassword(postgres.getPassword());

        HikariDataSource ds = new HikariDataSource(hikariConfig);
        Statement statement = ds.getConnection().createStatement();
        statement.execute("SELECT 1");
        ResultSet resultSet = statement.getResultSet();

        resultSet.next();
        int resultSetInt = resultSet.getInt(1);
        assertEquals("A basic SELECT query succeeds", 1, resultSetInt);
    }
}

[ldcasillas-progreso]

I cloned the repo, added a test like that, and it runs successfully. Let me try and build a 1.0.2-SNAPSHOT and see if that solves my original problem.

[ldcasillas-progreso]

Ok, I can now report that:

1. I can successfully maven install my branch, which runs all of the unit tests successfully plus your suggested one for @ClassRule.
2. Nevertheless, I still get the same error in my code base as I did before.

The logs show:

[Test worker] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying Environment variables, system properties and defaults. Resolved: 
    uri=https://192.168.99.100:2376
    sslConfig='LocalDirectorySSLConfig{dockerCertPath=/Users/luis.casillas/.docker/machine/machines/default}'
    version='{UNKNOWN_VERSION}'
    username='luis.casillas'
    password='null'
    email='null'
    serverAddress='https://index.docker.io/v1/'
    dockerCfgPath='/Users/luis.casillas/.dockercfg'

[Test worker] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Found docker client settings from environment
[Test worker] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Docker host IP address is 192.168.99.100
[Test worker] INFO org.testcontainers.DockerClientFactory - Disk utilization in Docker environment is 23%
[Test worker] INFO com.progressfin.dataplatform.DataPlatformETLTest - JDBC URL: jdbc:postgresql://192.168.99.100:null/test

So it looks like what you're guessing—my makeDataSource() method is being called before the container is created.

[ldcasillas-progreso]

Actually, looking at the code in my end, now it's clear what the problem is. The unit test suite in question has a bunch of unusual, custom logic, and the makeDataSource() method is being called from the test class' constructor. This is clearly a problem at my end.

I'll let you decide whether to close the ticket—I think my points about failing early are still worthy of consideration.

[rnorth]

Great - I'm glad you tracked it down.

And I'll definitely act on your feedback all the same, as you're correct. In fact, I'm working on this in PR #81 right now :)