[TFUI] Re: [TDD] Re: TDD at the GUI end
"Phlip" <[email protected]>
| Newsgroups | gmane.comp.programming.test-first-user-interfaces,gmane.comp.programming.test-driven-development |
|---|---|
| Message-ID | <006901c4f981$c5ff8050$0102a8c0@DF619121> |
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.
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.
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.
And control over the environment can lead to tests that run absolutely
silent, without any GUI displaying.
> 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".
For most test runs, your fingers should remain on the keyboard with the
editor unblocked. Regulating the event queue usually leads to these
improvements.
> 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?
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:
if (IDYES == MessageBox(...))
{...}
The best fix, when architecting a GUI Toolkit, is to pick a language with
block closures:
MessageBox(...) do |answer|
if IDYES == answer then
...
end
end
The latter has more ways for tests to get between the message box and the
production code.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
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/