Allow better support for test frameworks other than JUnit

[rnorth]

See #86 for background

[bsideup]

@rnorth I can take TestNG support since one of our projects is using it :) See #132

[rnorth]

Cool, thanks! In terms of structuring this, I think there's a reasonably chunky refactoring coming up in the future so it might be best to consider now. I'm thinking that:

• all docker support should be moved into a new maven module (named, e.g. containercore) that is completely test framework agnostic. Part of the rationale also includes potentially using the library in non-test contexts, BTW, which is admittedly a bit of a revision on my previous ROADMAP thinking ;)
• we'd have a separate maven module for JUnit 4 support. Note that JUnit 5 support would eventually have to be another module as @ Rule support is going away :(
• there would be another maven module for TestNG support. I don't have strong feelings about how the internals of this should be structured, but basically it looks like providing suitable base class(es) should be fairly idiomatic.
• The degree of change probably warrants this being a 'v2.0.0' release

This diagram roughly illustrates my thinking (please excuse the UML ;)):

What do you think?

[bsideup]

@rnorth looks good! I'm thinking about some refactorings before we start (especially in case of v2.0.0), will write them down to discuss a little bit later

[kiview]

I'd be very interested in a version of which does not include any JUnit dependencies. I'm currently developing a Docker extension for Spock (https://github.com/kiview/spock-docker-extension) and I'm using the Groovy Docker Client (https://github.com/gesellix/docker-client).

Lot's of the feature I still need add to my extension are already available in testcontainers in a quite accessible and convenient manner. So I wonder how I could best integrate testconainters into my project, or help in modularising the current version of the library. As for the time being I'm still hesistant in integrating this project as long as this will include JUnit dependencies.

[rnorth]

@kiview thanks for the comment - sorry for the delay in responding!

Yes, breaking the JUnit dependency is absolutely something I'd like to do, as you can see from this ticket.

It would probably be reasonable to do #240 at the same time; either as a separate JAR for DockerClientFactory, or make it a consciously public (exposed) member of the containercore lib. Personally I feel the latter would be reasonable. What do you think @bsideup?

[bsideup]

@rnorth sounds good for me. I have some free time this week, so I can take this task if you don't mind :) I see two tasks here - one for "JUnit-free core" and another one "separate DockerClientFactory", so we can split the work. WDYT?

[rnorth]

@bsideup sure, that'd be great! Does the diagram above make sense, or do you want to discuss any refinements?

DockerClientFactory would probably have to move into the new containercore JAR anyway, but yeah I'd imagine the tidy-up work to make DCF be a real reusable class can follow.

[bsideup]

@rnorth it looks good, but I can't say exactly until I start :)

Also, looks like there is only one open external PR, so I think it's a good time to start 2.x

[kiview]

I'll try to explain my use cases when using this library in conjunction with the spock extension:

• Convenient interface for creating and configuring containers
• Ability to pause and resume containers during tests
• Easy inspection of containers during tests (like getting IP)
• Docker-Compose support

Bonus points for Windows support with named pipes ;)

Another thing which would be awesome would be the possibility to run my tests inside a container, so I can use features like docker networking to access my testcontainers. But this seems like another project ;) (Gradle plugin maybe?)