Abort/retry/ignore vs. walkback?

Blair,

I recently wrote some fairly intense GUI unit tests, and started noticing a
pattern that might point to resource exhaustion.  The new tests fall toward
the middle of the SUnit Browser when it is showing all tests.  If I let it
run everything, it gets through the new tests, but I reliably get an
abort/retry/ignore message box instead of a walkback in some older tests.
The walkback is due to a #halt that I have in place to help me write a few
tests.

If I choose retry on the message box, a walkback appears, and a couple of
subsequent #halt sends result in a walkback w/o the message box.  If I run
all test except the new tests, I correctly get walkbacks instead of the
message boxes.

Any ideas?  This is happening on win2k.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
> I recently wrote some fairly intense GUI unit tests, and started noticing a
> pattern that might point to resource exhaustion.
> [...]
> Any ideas?  This is happening on win2k.

You never said what message is given with the abort/retry/ignore message
box.

If you haven't already, you might want to watch the windows task manager
(with most columns showing) while the tests are running. It might show
if some resource usage is growing too much.

It sounds like it might be an issue with some part of GC/finalization
that would otherwise be releasing windows resources not getting a chance
to run without any idle time? Once a walkback occurs, the resulting idle
time is allowing things to get cleaned up.

I have a (rather vague at this point) recollection of something similar
happening to me a year or so ago as I was getting GUI tests going. I try
to make sure that the #tearDown method explicitly does either #close or
#destroy on any top views that the test case might create. The #destroy
works well where a #close might end up prompting for unsaved changes.

Hope this helps.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> You never said what message is given with the abort/retry/ignore message
> box.

The callstack.  Correction to my earlier post: retry does not display a
walkback, it opens the debugger.


> If you haven't already, you might want to watch the windows task manager
> (with most columns showing) while the tests are running. It might show
> if some resource usage is growing too much.

It doesn't appear to be outrageous (though it does increase several times
over during the offending tests), but I added some explicit queue clearing.
That probably deserves some revision, at which point it will be easy to
completely disable to get a better comparison.


> I have a (rather vague at this point) recollection of something similar
> happening to me a year or so ago as I was getting GUI tests going. I try
> to make sure that the #tearDown method explicitly does either #close or
> #destroy on any top views that the test case might create. The #destroy
> works well where a #close might end up prompting for unsaved changes.

I've been using #ensure:, with aPresenter topShell presenter exit.  Thanks
for the tip about #destroy.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
> I've been using #ensure:, with aPresenter topShell presenter exit.  

I use something like that in a few places. But typically the #setUp is
creating the presenter or shell and I just leave it to #tearDown to
destroy it. In tests that are more toward the acceptance test side of
things, which may often open a series of windows, I'll have the
testCases add the shells that get opened to a collection in an abstract
superclass. Then the #tearDown in the abstract class takes care of doing
"aShell view destroy" for each one. Helps to keep the individual
testCase methods simpler.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA