Does anyone use the profiler for coverage analysis?

Dialogs are indeed pesky critters. Does anyone have a trick for using scripts to verify dialog behavior? Suppose automation is not possible. What are the alternatives?

Daniel provided “white box” insight (not surprisingly) to the modules that need testing. Let’s see if we can list some test cases…

In this case, there are several things that would need testing, all of which are non-trivial.

1) Testing that the getCurrentTimeDelta does the right thing. This is virtually impossible unless one has another atomic clock implementation to compare against, and even so it is difficult.

2)Test that the timer object works properly. This could be done by swapping out the dialog box for something else, setting the atmic delta to 0 and then clocking the time untill our callback is called.

3) Testing that the dialog box works. Plain difficult, as all GUI testing is.

–DA

For other scripts I don’t have a consistent way.

Sometimes I play around with it until I’m satisfied.

Sometimes I have a test script that I may or may not archive.

Sometimes I have the script look for the inputs - if the only input is the string ‘SelfTest’ I call a subfunction that contains all of the test cases, calling the main function recursively. These are usually the best maintained test cases.

Unfortunately, while I’ve used the Profiler to check the performance of the test cases, I usually forget to use the Profiler highlighting to check the coverage of the test cases. Does anyone use the Profiler output for coverage analysis?