Current practice is to write unit and integrations tests for development and integration servers only. Sometimes UAT can host the tests, but never production. The reasoning is understandable, but flawed. Production environments cannot be fully tested to make sure that environmental factors have not caused issues. UAT suffers the same fate if it is mirror production. Development and integration environments are quite different to production as they contain a complete set of new (test) code.
The answer is to start treating our tests as first class citizens. Don’t lock them out of production. Instead make sure that they are production ready. This is where zero footprint comes in – not only for the tests, but for any production code they exercise. The frameworks are there. Use dependency injection, interface or database table redirection and mocks. If your production code does not know test from production, then this is an opportunity to refactor.
Yes, this does add overhead. To be first class citizens, tests must behave – just as with other production code. Production code is consistent in changing data. Production test code is consistent in NOT changing data. Production code is polite when dealing with interfaces. Production test code uses mocks or known test interfaces.
And one more teeny-weeny overhead. For tests as first class citizens, they must be tested. The only tests required at this layer are to make sure of the zero footprint rule.