Can't get a new snapshot from jitpack.io.
@kiview How to circumvent the limitation? My project is hanged up while loading dependencies.

Testing inside CircleCI was a bit problematic, since CircleCI uses containers itself. Since we are now using TravisCI, it might be easier to only rely on TravisCI and remove CircleCI altogether?

This feature is still missing and crucial for some images like databases.

When trying to test a Spring-Boot app with an exclusive database container, it's necessary to start the container in the setupSpec() phase, so the first SpringApplicationContext can be initialized correctly.

Hi there,

I'm running into a very odd behaviour. Not sure if I've done something incorrectly. Would you be able to please take a quick look at this?

Here's my gradle build script that brings in testcontainers-spock

repositories {
    mavenCentral()
    maven { url 'https://jitpack.io' }
}

apply plugin: 'groovy'

dependencies {
    compile 'com.github.testcontainers:testcontainers-spock:673320b'
    compile 'org.codehaus.groovy.modules.http-builder:http-builder:0.7.1'

    testCompile 'org.apache.httpcomponents:httpclient:4.5.2'
}

///////// TEST CONFIGURATION /////////
test {
	testLogging {
		events "failed", "passed", "skipped", "started"
		exceptionFormat "full"
		showStackTraces true
        
		// when running Gradle with a '--info', display the stanard streams
		info.showStandardStreams = true
	}
}

I have a test class in <gradle-project>/src/test/groovy/my/org/docker/ directory. The test file is named MyIntegrationSpec.groovy

Inside MyIntegrationSpec.groovy, I can't seem to declare a custom package name. For example: package com.my.org.docker.service.test returns following error about @TestContainers not resolving. The only way my tests will execute is if I declare the package name as package com.groovycoder.spockdockerextension

Did I miss any particular configuration in my build? I also tried to import com.groovycoder.spockdockerextension but that doesn't work either. I get an additional error about not being able to resolve spockdockerextension class

unable to resolve class Testcontainers ,  unable to find class for annotation
 @ line 28, column 1.
   @Testcontainers
   ^

Currently, when specifying an image with tag (like "myImage:myTag"), it automatically expands to "myImage:myTag:latest" which seems rather wrong.

The test will start even if, for example, a port can't be bound and the container is thus not started. It would be much nicer if the test failed at a much earlier stage with a descriptive error message.

Something like the classic docker wait_for_it.sh script is needed, checking if TCP communication with the exposed port is possible.

Although Jitpack is a good solution, a mature library should provide their artifacts in Maven Central as well.

I have a problem with @Testcontainers annotation trying to start a container twice. I have a superclass and subclass. Both have some containers so both have @Testcontainers annotation. And it looks like the containers from the superclass are started 2 times, thus failing

Probably it would make sense to check org.testcontainers.containers.GenericContainer#isRunning before starting it in https://github.com/testcontainers/testcontainers-spock/blob/master/src/main/groovy/com/groovycoder/spockdockerextension/TestcontainersMethodInterceptor.groovy#L76

I use Selenium Webdriver:

    @Shared
    public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer()
            .withDesiredCapabilities(DesiredCapabilities.chrome())
            .withRecordingMode(RECORD_ALL, new File("./build/"))

But the recording always appeared under ./.tmp-volume-1503438720097/screen.flv.
How I can change this behavior?

Hi!

I see that you were inspired by https://github.com/FaustXVI/junit5-docker

We develop a library called TestContainers ( https://github.com/testcontainers/testcontainers-java ). It's mature, flexible and powerful engine to use Docker in your integration tests.

As the developer of junit5-docker already agreed to join the forces ( FaustXVI/junit5-docker#91 ), probably you will want to join us as well :)

We would really love to see some Spock/Groovy-native bindings for TestContainers, and it sounds like a great opportunity for you - to focus on it, instead of having to deal with the environment detection, container management, cleanups, etc...

WDYT?

Join our Slack anyway:
http://slack.testcontainers.org

Bonus point if combining method and class annotations works.

Hi,

I'm investigating to run integration testing on multiple docker containers/services in my project. I came across testcontainers which seems very interesting.

I cloned this repository and was able to run gradlew test, which successfully completes all the spock tests in this repository. I copied your spock test named ComposeContainerIT to my project. Didn't add any other logic for my own test case yet as I'm trying to just get started. I keep getting the following error message.

org.amimas.test.IntegrationTestSpecification > running compose defined container is accessible on configured port FAILED
    java.lang.IllegalStateException: Mapped port can only be obtained after the container is started
        at org.testcontainers.shaded.com.google.common.base.Preconditions.checkState(Preconditions.java:174)
        at org.testcontainers.containers.GenericContainer.getMappedPort(GenericContainer.java:793)
        at org.testcontainers.containers.DockerComposeContainer.getServicePort(DockerComposeContainer.java:324)
        at org.amimas.test.IntegrationTestSpecification.setup(IntegrationTestSpecification.groovy:24)

I've created a sample github repo with this issue. I'm not quite sure what missed. I can bring up the container manually by running docker-compose command. But, the spock test seems to be unable to start the container. The exact same test case runs fine on my machine when I run it from this repository. So, it's not an environment issue. Is there anything else that might be causing this error?

https://github.com/amimas/testcontainers-spock

I would like to be able to control - and gain information about - the spawned containers from inside the test. Here are two examples where that could be handy.

• For doing things such as recovery-tests or similar, where I would simulate a failure of collaborating systems, I could stop (and later restart) a container from within the test.
• For accessing the container independently of the docker setup (dind / wormhole / native), I could look up the containers IP from the handle.

There may be many other examples, of course...

Seems to be some problem in cleanupSpec event. Becomes very visible when testing with MySqlContainer, since it will fail then.

It's currently not possible to access containers that were defined using a docker-compose.yml

The Facade classes might still be useful in the future for allowing easier API changes or more idiomatic Groovy code without having to change code upstream. Still we want to expose the already existing functionalities of the testcontainers API.

It seems sensible to expose them via Groovy's @DeleGate field annotation.

When running the sample DatabaseTest from the docs, the following error occurs:

java.lang.IllegalStateException: Mapped port can only be obtained after the container is started