Home > Applications > App Development

Computerworld - In case you don't know it, without automation, software testing is hopeless. The latest development tools and component libraries allow developers to develop so much functionality so fast that it is literally impossible, actually inconceivable, that you can test the finished applications by hand. Most test budgets are measured in fractions of development, so it's not like you can spend more time and people testing than you do developing.

Of course it's easy for developers to automate unit testing; after all, they have control of the source. They can use debuggers, instrument their code, insert breakpoints, whatever. But if you have ever tried to automate black box automated testing, you quickly discover that test tools can't drive applications whose components aren't strictly vanilla. Custom controls, third party components, complex objects within containers and just about any user-defined or modified object classes give test tools fits. They can't get the object names, let alone the methods and properties needed to interact with them. (Getting good names is a whole other story—see Smarter Tools, Dumber Developers.)

	Linda Hayes is the CTO of WorkSoft Inc., developer of next-generation test automation solutions. She is the founder of three software companies and holds degrees in accounting, tax and law. A frequent industry speaker and award-winning author on software quality, she pioneered automated testing tools. Care to comment? Go here!

In my experience, more than half of all test automation time is spent—wasted—trying to deal with these complications, and in too many cases automation fails completely. But what is really inexcusable is that it doesn't have to be that way. Most test tools provide source code implants or DLL files that, when compiled into the code, give the tools access to the object names, methods and properties that are needed to do test automation. Adding this capability takes minutes—usually only a single line of code—but it can make the difference between automated and manual testing.

So what's the problem? In my opinion, it's either ignorance, paranoia or pure laziness.

Ignorance because a lot of companies think that if they compile in a test hook, then do the testing, then remove it for shipment that they have not really tested the production code. This is nonsense. True, the production code does not have the same hook as the tested version, but so long as the source is otherwise identical between the two compiles the only difference is the test hook.

The key is that these hooks don't do anything unless called. They are usually just a DLL that lets the tool inside the application's process space so it can see the objects. They only provide information, they don't alter or create it. So, compiling the code without the hook should have zero effect on the application functionality.