Earlier quoted context omitted.
> Unless you have a ten-line† program or one hell of a suite of unit tests documenting every single interaction with the world your system ever performs‡, you can never be sure that a first-day employee 'fixing' a bug hasn't introduced a new obscure one somewhere. New employee creates test to cover bug. Fixes bug. Runs test suite. Test suite passes. Commits code. All under the watchful eye of another developer. You k…
>> other than not being philosophically opposed to meaningless tests? > Just because you assume something is meaningless doesn't mean it is. For the record, I meant philosophically opposed to tests the tested believes to be meaningless - which is the only useful definition. Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bath…
Then, for the record, in this case, it helps to highlight people who think they know it all when they really don't.
> Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bathrooms and more like actual work.
Again, confusing execution and strategy.
But then again, you're philosophically opposed to tests the you believe are meaningless.