Re: [TFUI] Re: [TDD] Re: TDD at the GUI end

"Phlip" <[email protected]> writes:

> Anthony Williams wrote:
>
>> I realise you were suggesting mocking the message box, but my test doesn't
>> work that way --- the message box really pops up, and the test closes it
>> automatically, so no use input is required.
>
> I have never bothered to research how to close a Win32 MessageBox() window.
> Maybe you found an easy way, or maybe you walked the Desktop's window list
> until you found the message box.

My code walks the window list. It did annoy me that there wasn't an easy
way. It's not even easy to tell a message box from any other dialog box.

> Generally, if such research on the test side is taking you away from your
> project's general needs, not closer, I'd punt, use a mock object, and devote
> research time to cracking the GUI features that your project will find
> challenging.

Given the choice, that's what I'd do. However, having the parts that displayed
the message box untested was irritating me, and this now lets me pull them
under test. Now it's done, I can make use of it in other parts of the
application.

> Either way, testing GUIs first always requires learning to control your
> GUI's event queue. This might allow one to, for example, intercept the raw
> messages that were about to spawn the message box, and to snarf these.

It might. The MessageBox API blocks (as you note below), so you don't get an
opportunity to do this.

> And control over the environment can lead to tests that run absolutely
> silent, without any GUI displaying.

That'd be my ideal.

>> This, along with other
>> peculiarities about MFC (property sheets always steal the focus, even if
>> they're not visible, for example), does mean that the editor briefly loses
>> focus whilst the tests run, but it's a price I'm willing to pay.
>
> Oh, yeah. Thanks for reminding me. Traditional debugger-oriented IDEs force
> the GUI to display, and collect input, as a "feature".

Yes, it's a pain.

> For most test runs, your fingers should remain on the keyboard with the
> editor unblocked. Regulating the event queue usually leads to these
> improvements.

Agreed.

>> Yes, it's a "gotcha" for the toolkit, but that's precisely why I wrote the
>> special assert macro --- it's a workaround for the problem.
>
> What did you call to kill the message box?

My assert spawns a thread that watches for the message box to appear, and then
sends it a WM_CLOSE message.

> And note, in general, that functions like MessageBox() or DoModal() contain
> a false "convenience"; they block until their raised window closes. This
> couples control flow to the calling function, merely so you can apply the
> trivial convenience of writing an 'if' statement:

Yes. In new code, I avoid such calls. However, this is a legacy app, and it is
rife with them.

> The best fix, when architecting a GUI Toolkit, is to pick a language with
> block closures:

Maybe. 

Anthony
-- 
Anthony Williams
Software Developer



To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/