Re: [TFUI] Dialogs and EventHandlers

Owen Rogers <[email protected]> writes:

> hi anthony,

Hi Owen,

> On 07/11/05, Anthony Williams <anthony_w.geo-/[email protected]> wrote:
>> The key difference is that I believe the GetFontFromUserSelection function
>> does not belong on the MyForm class, so I would extract it to a collaborator
>> instead of mocking the FontDialog.
>
> just to play devil's advocate here:
> - it now looks like all of the functionality has been extracted to the
> SelectFontUsingFontDialog class.  so what are we really testing here
> (aside from the event handler calling the collaborator correctly)?  i
> can see the value from a design perspective, but the original question
> was how to test it.

The original design had two aspects to test --- did the menu click ask the
user for a new font, and did the font get changed to the new one. By splitting
off the separate class we allow for testing the two things separately.

>> We can then test the SelectFontUsingFontDialog class separately --- since it
>> now has a simpler interface, and a clearer responsibility, this is easier
>> than testing the original code.
>
> so, how might we do this then?  

I knew someone would ask that!

I've done this several ways. One way that works quite well is to run the
function with the modal dialog in a separate thread, check that it displays
the dialog, send messages to the controls from the test thread, and verify the
result.

> isn't this the crux of TFUI and also
> the intent of the original question?

Yes, and no. I believe there is more to the original question than how to
drive the GUI.

> also, is the interface necessarily better?  what if we wanted to act
> differently if the DialogResult was OK?  how would that impact the
> design?

If you need different behaviour on OK, write a test for it that forces the
GetFontFromUserSelection to tell you whether it was OK was clicked.

>> I might even decide it was "too simple to break", since all it does is call
>> a library component to select the font.
>
> is this a cop-out?  this code we deemed "too simple to break" looks
> more complicated than the code that we did write a test for.

Possibly. I did say "might" :-)

>> In particular, I feel that if you have a function that needs to ask the
>> user for a choice here and now, in order to perform some operation, then
>> the responsibility for obtaining the user's choice does not belong with
>> that function, and probably doesn't belong with the function's containing
>> class either.
>
> i agree.  but what if the dialog was not modal?  how would we handle
> this situation?  raising events from the dialog class?

Hmm. I don't know how I'd handle it, but that sounds reasonable. I'd have to
actually write code that needed it to work like that to be sure.

> to clarify: i'm not trying to poke holes in your article; i'm just
> interested in exploring this issue.

Thanks. That's why I wrote the article in response to Cory's --- to explore
the issues.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~-> 

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/