Some errors cause a NoClassDefFoundError and the real error is hidden

In certain cases a test may fail with a NoClassDefFoundError, and it's a nightmare to find the real error.

For example:

static final PostgreSQLContainer = PostgreSQLContainer("postgresxxx:11.5") 
    .withDatabaseName("netonomy")
    .withUsername("postgres")
    .withPassword("password");

Then running gradle test results in:

com.example.SomeIntegrationTest > testPostgres() FAILED
    java.lang.NoClassDefFoundError: Could not initialize class com.example.SomeIntegrationTest

To find out the actual error, it was necessary to run Gradle with --info. I only used a bad image name here as an example to reproduce - the real error was "Docker environment should have more than 2GB free disk space", and it happened only on the CI build agent - so this was a real nightmare to diagnose!

What makes this even more difficult to pin down is the fact that even removing the @Testcontainers and @Container still results in the exact same behaviour!

The reason for all of this, is the fact that GenericContainer's constructor calls this.setDockerImageName() which in turn calls getDockerImageName() which actually attempts to get the image: https://github.com/testcontainers/testcontainers-java/blob/master/core/src/main/java/org/testcontainers/containers/GenericContainer.java#L1057

IMO this is an action that should not take place in a constructor - this should happen only later during start(). Either way there ought to be some better solution, because diagnosing errors this way is a nightmare.

Beginne in core/src/main/java/org/testcontainers/containers/GenericContainer.java bei dem referenzierten Aufruf von getDockerImageName() und verfolge, wie die Konstruktion die Image-Auflösung auslöst. Reproduziere das Beispiel mit gradle test und vergleiche die Standardausgabe mit --info. Erledigt ist es, wenn der zugrunde liegende Container- oder Docker-Fehler diagnostizierbar ist, ohne hinter NoClassDefFoundError verborgen zu werden.