Debugging the proxy code
Debugging the proxy code is an essential part of the proxy development
process for problem determination. The proxy code containing the JAR file
or .Net assembly file with the .dll extension is loaded into the application
under test (AUT) process. To debug the proxy code, attach the respective debugger
to the AUT process after the proxy binary files are loaded into the AUT.
- Implementing logs for proxy code debug
Functional Tester provides a log
infrastructure that you can use while debugging the developed proxy code.
The FTDebug class is available in both Java™ and .Net proxy development frameworks.
You can instantiate an object of the FTDebug class for each proxy class and
log any information, warning, or error message categorically.
Preparing the debug environment
Before you debug the proxy code, perform the following tasks:
Setting invocation timeout
Debugging proxies is time sensitive and the invocation times out
after two minutes by default. To adjust timeout for debugging, add a DWORD
value InvocationTimeout in milliseconds under HKEY_LOCAL_MACHINE\SOFTWARE\Rational
Software\RationalTest\8\Options in the Windows registry. A timeout during
debugging throws a SpyMemory MutexTimeout exception.
Debugging record
The getChildAtPoint() method is the entry point for proxy debugging
for record. Any user action calls the processMouseEvent() method, even before
AUT sees the event. Functional Tester processes
the user actions, for example whether the action is a click or drag and accordingly
the method specification and arguments are generated. For best results, use
these methods to start inserting breakpoints.
Debugging playback
The getMappableChildren() method is the entry point for proxy debugging
for playback. During proxy development, most ObjectNotFound problems that
occur result from a mismatch between the object hierarchy that the record
produces and the hierarchy produced during playback. Make sure that the getMappableParent()
and getMappableChildren() methods are symmetrical.