Sometimes the desired behaviour is actually generating a Docker image with specific contents. Think of the pause container image that every Kubernetes cluster out there uses. To put it in other way, this is for build targets producing Docker images that are needed by an arbitrary set of projects, possibly from third parties.
Suppose you have an organization-wide Docker image from which tens of other images from a number of teams are derived. You could add a test to make sure that the ca.crt file is always packaged and never empty or you could let tens of downstream tests and images fail in mysterious ways when it's missing (unless you replicate the check in all projects depending on the base image).
The use case is more for infrastructure that explicitly deals with or supports containers. Generic applications, as you say, shouldn't bother.
The pause container is very much an implementation detail. That's sort of my point. Why would you try to test implementation details?
>You could add a test to make sure that the ca.crt file is always packaged
I could, but why? If I wrote a command to put ca.crt there I would expect it to be there unless somebody deliberately took it out.
It would be even better if I wrote a command to put ca.crt in the wrong place and then tested to see that it was in the wrong place. The test would be worse than useless in that case - it would fail on a working container and pass on a broken container.
The ca.crt is there because it triggers desired behavior - e.g. that you can connect to services over SSL without errors. Test that instead.
>The use case is more for infrastructure that explicitly deals with or supports containers.
Personally I'd consider containers themselves an implementation detail most of the time - the exception being when you're building containers for other people to use.
I still think it's the wrong approach for that too.
You can mix and match between tests that check file contents and tests that actually run commands inside the container and make assertions based on their output.
Maintainer of the tool here - this is definitely the main use-case. We produce container images that are used directly or indirectly (as a base image by other users), and the structure tests here are a way for us to define the contract our container exposes and test/verify that we continue to maintain that contract quickly and easily.
Suppose you have an organization-wide Docker image from which tens of other images from a number of teams are derived. You could add a test to make sure that the ca.crt file is always packaged and never empty or you could let tens of downstream tests and images fail in mysterious ways when it's missing (unless you replicate the check in all projects depending on the base image).
The use case is more for infrastructure that explicitly deals with or supports containers. Generic applications, as you say, shouldn't bother.