Imagine a discussion between four people - one a developer, one a manager, one a tester and one a deployment/operations type.
The Manager is very angry as a system has fallen over after a new version of code was deployed into production. He is looking to point fingers.
Operations person pleads ignorance - they followed the deployment steps exactly.
Tester pleads ignorance - they have functionally tested code and it worked fine in test environment.
Development person pleads ignorance - they provided good code, and claim that the system badly configured.
This situation may seem familiar to some. There's always an excuse, some mistake made along the chain - from design to deployment - that allows a system to be upgraded but doesn't work as intended.
What are the pros and cons of diagnosis testing - tests run built into the application (perhaps through a command line API or something) that would allow a system to check it's internal connections (database, middleware, filesystem etc) and confirm that everything it expects to work is correct?
This is rather than relying on an external monitoring system that may not be configured in the same fashion as the application? (new release, different properties, looking at the wrong database etc)
An example :
I'm writing a class that interacts with a database. Within this class, I create a method that interacts with the database without affecting it, say a simple select query.
In the constructor of this class, I pass to an observer a test based on the arguments passed into the constructor. This observer can be called to run all the tests it has at any time so as to test for the validity of the connection - even while the system is actually running.