Ads by TechWords

See your link here
Receive the latest technology news and information.
Application/Web Development
Computerworld Daily News (First Look and Wrap-Up)
Computerworld Blogs Newsletter
The Weekly Top 10
Cloud Computing
View all newsletters




Privacy Policy
 

Give Me a Test Hook ¿ or Else

April 2, 2003 12:00 PM ET

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.)











DevTalk

Linda Hayes

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.



Jump to comments

Development

Additional Resources

Xerox
By using solid ink technology only from Xerox, you could save up to 65% by printing color for the cost of black and white. Enter for a chance to WIN a PhaserTM 8860 network color printer!
Microsoft
Save time and mitigate security risk. Deploy it now.
Sybase
In this white paper, IDC analyzes the role of next-generation mobile enterprise platforms as organizations seek a more strategic deployment of mobile solutions.

Learn the important issues you must consider before starting your next mobility initiative. Get your mobility white paper from IDC now, compliments of Sybase.