[gedrap]

I get you, wrong wording, it's not exactly a standard unit test, etc. But it doesn't change the meaning and intention of it - treat infrastructure as you treat code (I guess that also includes debating whether something is a 'unit' test or 'other' kind of test).

Also, having a file on a container (which is probably the easiest test to perform) often is _the desired behavior_ of a command or something else.

[crdoconnor]

>I get you, wrong wording

No. Not that.

>Also, having a file on a container (which is probably the easiest test to perform) often is _the desired behavior_

No it isn't. The end user doesn't give a damn whether a particular file is on the container. That's an implementation detail. The end user wants:

* Pages to load quickly

* To not have to face data inconsistency bugs

* Pages to operate while the site is under high load

* For various services your system connects to to work properly (e.g. clicking 'get two factor code' actually sends an SMS).

Checking to see if a certain file is present is pointless if that doesn't lead to the desired system behavior.

Moreover, if you have the means to verify the desired system behavior:

* The presence of the file, if it was required, can be assumed.

* If you swap out a component and stop needing that file to be present to achieve the same behavior your test will still fail even if your system works perfectly. That's an extremely undesirable property to have in a test.

Checking for the presence of a file and failing hard if it is not there as part of a build is a sometimes a good way sanity checking a component, but as an outside 'test' of that component it's a bad idea.

[yorwba]

The "end user" of a container image may very well be another developer who wants to run his code in there and depends on the existence of said file.

[crdoconnor]

In which case it would make most sense to build a mock container on top which clearly exhibits the desired behavior of the underlying container and then test the behavior of that.

[dlor]

Maintainer of the tool here - I'm not sure I understand this idea. What would go in the mock container? How would you test against it? Would you mind elaborating a little more?

[crdoconnor]

Exactly what rad_gruchalski said.

I'm assuming that in this case the base container would be a 'ruby' container or something. You'd build an example container atop it running a bit of example ruby code - verifying that it behaves properly. Those behavioral tests could be used to verify that the underlying container is configured properly.

I suppose that's sort of what you're doing in the example you linked to above.

[rad_gruchalski]

I guess an "example". I generally agree with the parent poster. Testing for files does not sound useful. Test the functionality, not structurue. But not everyone's google.