Difference between StartupCheckStrategy and WaitStrategy in test containers

Question

Recently we had issue with starting time of some of our test container: Slow computer just couldn't start container withing hardcoded 30 seconds.

Issue was resolved by moving all our checks to WaitStrategy which has configurable timeout.

Is there any reason for keeping both checks? And what should be checked in StartupCheckStrategy and in WaitStrategy?

Answer 1

Sorry that it's a bit confusing!

StartupCheckStrategy is for checking whether Docker managed to start the container at all. There are a couple of different variations, but basically it's just 'did the container reach the RUNNING state?'.

Just because the container is running, though, it doesn't mean it's actually ready to do anything useful (eg to accept connections or do work) - this is what the WaitStrategy is for. The default wait checks are simply probing to make sure TCP ports are listening, but you can override these with more sophisticated checks, eg trying to establish a connection via a driver or looking for log strings.

It sounds like you did the right thing by moving your checks to a WaitStrategy implementation. Sorry again that it's confusing; we clearly need to do a bit of work on the docs to make it easier to understand and more consistent.