headers
Cory Foy | 4 Nov 2005 17:33

[TFUI] Dialogs and EventHandlers

Hi All,

Recently on the NUnit list someone emailed in trying to figure out how 
to test "private void" methods. Turns out they were wanting to test an 
event handler that opened a FontDialog, which in turn set the font of 
the form.

While my first reaction was that it was probably easiest to test it 
manually, I decided to give it a shot to create an automated way to test it.

I'd love you have your feedback on if this would have been the approach 
you would have taken and anything else I could have done differently:

http://www.cornetdesign.com/2005/11/writing-tests-for-private-void-classes.html

Thanks so much!

Cory

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links

<*> To visit your group on the web, go to:
(Continue reading)

Permalink | Reply | 20 comments |
headers
Scott Bellware | 4 Nov 2005 19:10
Picon
Favicon

[TFUI] Re: Dialogs and EventHandlers

Cory Foy <usergroup <at> c...> wrote:
> I'd love you have your feedback on if this would have been the
> approach you would have taken and anything else I could have done
> differently

Great post!

If you're going to add a configuration item to influence which 
IFontDialog that the FontDialogFactory will create, why not just put 
the class name of the font dialog in the config and then instantiate 
it using the System.Reflection.Actovator?  This will free your code 
from external environmental conditions (like, IS-THIS-A-TEST), and 
will knock a couple Cyclomatic Complexity points off of the 
GetFontDialog method.

And... if you add the class name to configuration, you might as well 
just use Spring to activate the instance using it's XmlObjectFactory 
or ApplicationContext so that you don't have to write the activation 
code yourself :)

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hristo Deshev | 4 Nov 2005 20:44
Picon
Gravatar

Re: [TFUI] Dialogs and EventHandlers

Hi Cory,

Nice post and a nice blog. I added it to my Bloglines list :).

On 11/4/05, Cory Foy <usergroup@...> wrote:
>
> Hi All,

> I'd love you have your feedback on if this would have been the approach
> you would have taken and anything else I could have done differently:
>
>
> http://www.cornetdesign.com/2005/11/writing-tests-for-private-void-classes.html

This whole factory and configuration thing looks a bit too much to me. I
usually do a thing, Michael Feathers calls "Subclass and override" in his
Working Effectively with Legacy Code book. I pulled the FontDialog creation
from your code in a separate method:

protected virtual IFontDialog CreateFontDialog()
{
return new TestableFontDialog();
}

and overrode that in a testing subclass:

protected override IFontDialog CreateFontDialog()
{
return new MockFontDialog();
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 5 Nov 2005 03:28
Favicon

Re: [TFUI] Dialogs and EventHandlers

On Friday, November 4, 2005, at 8:33:13 AM, Cory Foy wrote:

> I'd love you have your feedback on if this would have been the approach
> you would have taken and anything else I could have done differently:

> http://www.cornetdesign.com/2005/11/writing-tests-for-private-void-classes.html

Cory ... my initial feedback is that on my laptop, running
Maxthon/IE, the code font is pink on white, and very tiny.

I'll try to read through and offer something more focused on the
ideas!

Ron Jeffries
www.XProgramming.com
Resistance may or may not be futile. It is for sure not productive.

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links

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

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 5 Nov 2005 04:37
Favicon

Re: [TFUI] Dialogs and EventHandlers

On Friday, November 4, 2005, at 8:33:13 AM, Cory Foy wrote:

> Recently on the NUnit list someone emailed in trying to figure out how
> to test "private void" methods. Turns out they were wanting to test an
> event handler that opened a FontDialog, which in turn set the font of
> the form.

> While my first reaction was that it was probably easiest to test it 
> manually, I decided to give it a shot to create an automated way to test it.

> I'd love you have your feedback on if this would have been the approach
> you would have taken and anything else I could have done differently:

> http://www.cornetdesign.com/2005/11/writing-tests-for-private-void-classes.html

Looks nice ... it felt a little less test-driven than I was
comfortable with, but I don't see a way around that.

In the FontFactory, I might have had the factory contain a default
implementation consisting of an instance of the real font, and
override that with my test instance with a static setter that I
could fire from the test, rather than the boolean.

Whether I did that or not would depend on how much in my way the
language got. I probably wouldn't use reflection, as one of the
notes suggested, in Java, but in Smalltalk, where a class is an
object I might well just store the class in the variable and send in
the message new (since in Smalltalk new is a message, not a
keyword).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anthony Williams | 7 Nov 2005 12:18
Picon
Favicon

Re: [TFUI] Dialogs and EventHandlers

Cory Foy <usergroup@...> writes:

> Recently on the NUnit list someone emailed in trying to figure out how 
> to test "private void" methods. Turns out they were wanting to test an 
> event handler that opened a FontDialog, which in turn set the font of 
> the form.

> I'd love you have your feedback on if this would have been the approach 
> you would have taken and anything else I could have done differently:
>
> http://www.cornetdesign.com/2005/11/writing-tests-for-private-void-classes.html

I just posted an entry on my blog about this, describing what I would do
differently:

http://www.livejournal.com/users/anthony_w/8000.html

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.

Anthony
--

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

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Tim Haughton | 7 Nov 2005 10:11
Picon
Gravatar

[TFUI] Mocking .Net Controls/Forms

Hi, I recently added a new type of dynamic mock to NMock. The mock was
originally designed to mock out some remoted classes, but works with
any MarshalByRefObject, so it works with any .Net Control/Form. Also,
unlike the existing dynamic mock, this new mock will be able to mock
*any* methods, not just virtual ones.

In case the NMock team don't [want / get around] to adding it to a
release, I thought I'd post them here for reference. Comments and
flames welcome.

Cheers,

Tim Haughton

//*********MarshalByRefMock.cs*********************
using System;
using NMock;

namespace NMock.Remoting
{
	public class MarshalByRefMock : Mock
	{
		private Proxy proxy;

		public MarshalByRefMock( Type type )
			: this( type, "Mock" + type.Name )
		{
		}

		public MarshalByRefMock( Type type, string name )
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ed Howland | 7 Nov 2005 15:37
Picon

Re: [TFUI] Dialogs and EventHandlers

On 11/7/05, Anthony Williams <anthony_w.geo@...> wrote:
>
>  I just posted an entry on my blog about this, describing what I would do
>  differently:
>
>  http://www.livejournal.com/users/anthony_w/8000.html
>
>  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.
>
>  Anthony

Hi Anthony,

Two points about your approach. I notice your  
form.menuItem15_Click(null, null); is still private on your MyForm
class. And you should be able to mock with NMock or the built in
DynamicMock in NUnit in your test.

  DynamicMock mock = new DynamicMock(typeof(FontSelector);

  MyForm form = new MyForm((FontSelector)mock);
  mock.ExpectAndReturn("GetFontFromUserSelection", expectedFont, defaultFont);
  ...
   form.menuItem15_Click(null, null);
   mock.Verify()
   Assert.AreEqual(expectedFont, form.Display.Font);

This has the advantage of not needing another class
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anthony Williams | 7 Nov 2005 16:07
Picon
Favicon

Re: [TFUI] Dialogs and EventHandlers

Ed Howland <ed.howland@...> writes:

> On 11/7/05, Anthony Williams
> <anthony_w.geo@...> wrote:
>>
>>  I just posted an entry on my blog about this, describing what I would do
>>  differently:
>>
>>  http://www.livejournal.com/users/anthony_w/8000.html
>>
>>  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.

> Two points about your approach. I notice your  
> form.menuItem15_Click(null, null); is still private on your MyForm
> class. And you should be able to mock with NMock or the built in
> DynamicMock in NUnit in your test.
>
>   DynamicMock mock = new DynamicMock(typeof(FontSelector);
>
>   MyForm form = new MyForm((FontSelector)mock);
>   mock.ExpectAndReturn("GetFontFromUserSelection", expectedFont, defaultFont);
>   ...
>    form.menuItem15_Click(null, null);
>    mock.Verify()
>    Assert.AreEqual(expectedFont, form.Display.Font);
>
> This has the advantage of not needing another class
> (MockFontSelector.) And you can easily test the wiring across the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Owen Rogers | 8 Nov 2005 07:02
Picon

Re: [TFUI] Dialogs and EventHandlers

hi anthony,

On 07/11/05, Anthony Williams <anthony_w.geo <at> yahoo.com> 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.

> 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?  isn't this the crux of TFUI and also
the intent of the original question?

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

> 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.

> In particular, I feel that if you have a function that needs to ask the user for a choice here and now, in order
(Continue reading)

Permalink | Reply | 3 comments |

Gmane