[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.