Open rnorth opened 3 years ago
I can take it.
@rnorth I noticed that Testcontainers heavily uses static classes, for example:
try {
ExecResult result = ExecInContainerPattern.execInContainer(waitStrategyTarget
or
default Container.ExecResult execInContainer(Charset outputCharset, String... command) throws UnsupportedOperationException, IOException, InterruptedException {
return ExecInContainerPattern.execInContainer(getContainerInfo(), outputCharset, command);
}
which makes it hard to unit test/mock some things. Is it done on purpose or have there been any ideas to change that?
Asking that because fixing this issue would require to run an integration test which is heavier and I read in some issue that it's not desirable to increase build running time with heavy tests.
@vcvitaly overall, we prefer integration tests over unit tests. We do recommend avoiding unnecessary load on our CI but we don't mind it if it is needed.
Also, Testcontainers' nature is context-less, to make it easier to use in tests, hence the heavy usage of static objects.
If an error is thrown, HostPortWaitStrategy
will be running Unreliables.retryUntilTrue
until the timeout is reached.
I think in such cases as this it should be aborted immediately on some specific exception, however at the moment it's not possible with Unreliables
.
I described the issue in https://github.com/rnorth/duct-tape/issues/11
Hi, I have create this PR https://github.com/testcontainers/testcontainers-java/pull/6942 pls take a look and say what do you think? Thx
Relates to #2984
I'm surprised we've not come across this earlier, but the default TCP port listening detector
InternalCommandPortListeningCheck
does not work for containers that do not have/bin/sh
included.This predominantly affects images built upon
scratch
.The workaround/solution is to use a more application specific
WaitStrategy
- e.g. an HTTP wait strategy.However the log messages don't make this easy to realise.
Given that we do both the internal and external port checks for a good reason, I don't think we can just rely on the external port check. Still perhaps we can raise a very specific error message if
/bin/sh
is not available inside the container.