When docker isnt present

[npetzall]

Would be nice if one could tell the subclass of GenericContainer that one is assume-ing that docker is present. So that if someone that doesn't have docker, get ignored tests instead of failing tests.

Due to the fact
DockerClient is instantiated during of GenericContainer. One has no ability to use the jUnit way of conditionally ignoring tests with assumThat and AssumptionExceptionViolation.

Instead one gets:

java.lang.ExceptionInInitializerError
	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
	at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142)
	at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088)
	at java.lang.reflect.Field.getFieldAccessor(Field.java:1069)
	at java.lang.reflect.Field.get(Field.java:393)
	at org.junit.runners.model.FrameworkField.get(FrameworkField.java:73)
	at org.junit.runners.model.TestClass.getAnnotatedFieldValues(TestClass.java:230)
	at org.junit.runners.ParentRunner.classRules(ParentRunner.java:255)
	at org.junit.runners.ParentRunner.withClassRules(ParentRunner.java:244)
	at org.junit.runners.ParentRunner.classBlock(ParentRunner.java:194)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:362) 

So create the DockerClient later should make it possible to use assumptions if one would like to.

Also noticed that there is a getName after setting name that causes issues with the creation of the object. One would say it's doing to much in its construction, there is a "start" phase.

[npetzall]

Some discussion before I implement and PR?

[kiview]

IMO letting the test fail is the correct behavior.

[npetzall]

If the test was actually to run docker I would agree.
But having issues with docker doesn't actually tell you anything about your actual test.

As an example. I'm using JDBCContainer to spin up a mysql db and then performing some operations.
I verify that said operations have resulted in a specific state.

Should I assume that the operations are failing which is the actual test?

jUnit Assume would mark them as ignored and as such would not require everyone working with the project to have docker installed. You just make sure that the CI env has docker.

[martin-g]

Thinking the same way: what if MySQL is not available for any reason ? Do you expect your tests to fail or to be ignored ?

I agree with @kiview that failure is the correct behavior.

[npetzall]

Might have been unclear, since I don't want a breaking change I just want the ability to do something like:

@ClassRule
MysqlContainer mysqlContainer = new MysqlContainer().assumeDocker(); 

And this is since there is no good way of ignoring test that you know are going to fail.

[npetzall]

The whole idea behind assumptions is that tests should not fail just because you made an assumption. They will not pass, they will not fail.

And adding this to ones project just makes the assumption that people aren't on Windows and that everybody has docker installed. (it does work on windows with limitation which seesm to be related to Compose, got the information from the slack channel)

Letting me as the user control this assumption would be a great thing IMO.

[npetzall]

If the ability to assumeDocker or ability to create assumptions easy on your own is not wanted this can be closed.

I however strongly feel that failing a DAO test because of container failure or missing docker is wrong.
Since SUT(System/subject under test) is the DAO and not the testcontainers/docker.
Had it been a manual test, it would has been marked as Not run aka Ignored. Ignored is an unknown state in regards to the SUT. Fail tests where the SUT hasn't failed. Test results should report state of SUT and not the test and/or environment.

[kiview]

Let's wait for the opinion of @rnorth.

[rnorth]

Thanks all, and I'm sorry I haven't replied on this thread until now. It's an interesting suggestion; I've used Assume once or twice but not come across use in the wild much, so you're the first person to ask for this. I can see how you'd find this useful, though. I can also see how Testcontainers has unique information about the Docker environment that is useful for such a Assumption. It won't be something that everyone wants to use, so I'd like to find a way to do it that's not too far-reaching. How about this: Could we perhaps proceed to do this separately from the container classes? E.g. Create something to allow either `assumeTrue(DockerClientFactory.isDockerAvailable())`, or `DockerAvailableAssumption.assumeDockerAvailable()`? Another reason for keeping it off the container classes is that I'd like to separate out any JUnit coupling from the container classes, so adding an assume method right now would seem to be a step in the wrong direction. Thoughts on the above approach? Richard

[npetzall]

@rnorth
1, Due to the creation of DockerClient during the construction of the class, it sort of falls on TestContainer to support this.
2, I've already implemented this it's with an added fluent .assumeDocker() so it's opt-in
3, The container classes already implements TestRule from jUnit, so it's already coupled.
Since assume is just more or less a bubbling exception i just added a new "phase" in FailureDetectingExternalResource which is assumptions which is called before start. I was thinking of just using a list of Functions so that assumptions could be added willy-nilly. Just to prevent the start from happening (avoid starting the container realize that the jdbc-driver is missing retry for 120s and so on and so on)

Since I have my fork and jitpack exists, this is not much of an issue.

[npetzall]

@rnorth @kiview @martin-g

SimpleMariaDBTest.java

Depends on what is considered "in the wild".
Should that assume be removed to get that failing test since it doesn't have a correct environment?

[martin-g]

@npetzall Yes, I think this assumption should be removed. I see no reason this test to fail on Windows.
But I get your point!
I just don't agree that a test that uses TestContainers library should not fail when Docker is not available or fails to start for any reason. TestContainers library is about Docker! If Docker is not there then the whole test has no meaning.
To me it sounds like javac printing warnings while compiling the test in absence of JUnit in the classpath. It is an error!

[npetzall]

@martin-g I don't care anymore.

But I agree with you "If Docker is not there then the whole test has no meaning" ergo Ignored, since Pass/Fail both have meaning.

[npetzall]

@rnorth
You could do composition over inheritance and remove the implements TestRule and the starting(Description description). Create a new module junit and just have a ContainerRule which takes a supplier as it's constructor argument.