Give Me a Test Hook ¿ or Else
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 storysee 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 spentwastedtrying 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 minutesusually only a single line of codebut 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.
Development
Additional Resources



Learn the important issues you must consider before starting your next mobility initiative. Get your mobility white paper from IDC now, compliments of Sybase.
White Papers & Webcasts
Extend, Replace, or Convert; which is the best way forward for COBOL Applications?
Download this white paper, free, compliments of Micro Focus!
Data Manager Report Excerpt: File System Inventory
Cut storage costs and boost operational efficiencies.
Key Strategies for Managing Data Growth
What are you storage challenges?
Reducing Storage Costs with F5 ARX
Save money- deploy ARX Solutions.
Extending Client Refresh - 11 Steps to Maximize Savings
Register Now!
Southern Company
Download Now
Lower the Cost and Complexity of a Mobile Workforce through Automation
Download This Resource Now!
Defending Against the Storm
Download Now
Managing Mobility: Improve Data Security, Compliance and Manageability
Download This Resource Now!


