I often use Server Management Objects (SMO) for automating database processes. Although it enables me to do powerful magic, and I am convinced of how useful it is, it is nonetheless a strange and rather irritating experience to use it. It has obviously been designed primarily for supporting the SSMS application, and the bare minimum of concessions have been made to allow it to be used for the important task of automating the work of the DBA and database developer. Dodging the unhandled exceptions and raggedness of the system becomes a sort of mental agility game, and are great for teaching the developer about the futility and frustrations of existence. However, it makes the process of SMO scripting rather more frustrating that one would like.

Although I have no idea how SMO was developed, it gives every appearance of being a great example of the result of a too-heavy reliance on automated testing at the expense of manual exploratory testing. It is a difficult balance.

A really thorough automated test regime will result in a system that works absolutely reliably if used in exactly the way that the testers envisaged. Without further exploratory testing, it will provide a system that can be surprisingly brittle when used in any way that the testers didn't, or couldn't, predict.

I have every sympathy for the developers of SMO: it is an ambitious system that supports SSMS with great aplomb. To make this into an API that can be used more generally is a bold step, but this sort of public API requires a test effort that is different in its scale and character to a private API, where the usage can be predicted and controlled. It also requires a prodigious effort in providing examples of use, documentation and tutorial materials. Of course, we in the SQL Server community can do a lot to help with books and articles but even here there are limits to what we can do to assist.

I hesitate to criticize SMO in any way, as I rely on it daily. Once you get a script to work, it generally stays working. I mention it only as an illustration of what happens when you rely on automated testing. It always makes me flinch to read of applications that claim to have 'automated all their test'. The real world just isn't like that. Applications, especially database applications, can fail in exasperating and mysterious ways. Whenever one of my databases falls from grace, I clutch my forehead and cry out 'How on earth could I have predicted that?' Well, expert testers can do just that, and their skills and malicious cunning can never be matched by automated testing.

Phil Factor