Comments on: Writing tests for private void classes

By: Cory Foy

Cory Foy — Tue, 08 Nov 2005 02:08:00 +0000

"I think the revision has changed behavior. In the original, the current font was unaffected if the user clicked cancel; in the revision, it is set to the default. So I'd write a test where the current font was not default and cancel gets "clicked"."

Hi Carl,

You do have a point, although the Font technically wouldn't change, since the default font is passed in, so if the user hits cancel it would just get set to what it was before.

This could cause events to fire, like OnFontChange events. So perhaps extracting the method wasn't the best way to preserve behavior.

Thanks for pointing it out!

By: Anthony Williams

Anthony Williams — Mon, 07 Nov 2005 06:15:00 +0000

I think that the GetFontFromUserSeletion function belongs on a separate class. I have added an entry to my blog giving more detail at: http://www.livejournal.com/users/anthony_w/8000.html

By: Anonymous

Anonymous — Sat, 05 Nov 2005 11:40:00 +0000

Cory…don’t know if this’ll make it back to you or not, sure hope so. Please tell Crissie that I thoroughly enjoyed the tour of your photo gallery – “baby”, wedding pics, and especially Gail’s awesome “jump”! Glad you all are doing so great! Good luck w/the pregnancy and baby preparations. Give “Mommy” a big hug from a very looooong time old friend and fan! Cheers…BJ

By: Carl

Carl — Sat, 05 Nov 2005 11:21:00 +0000

I think the revision has changed behavior. In the original, the current font was unaffected if the user clicked cancel; in the revision, it is set to the default. So I’d write a test where the current font was not default and cancel gets “clicked”.

By: Scott Bellware

Scott Bellware — Fri, 04 Nov 2005 13:12:00 +0000

Doh! That should have read “…knock a couple Cyclomatic Complexity points off of the…”

By: Scott Bellware

Scott Bellware — Fri, 04 Nov 2005 13:08:00 +0000

Great post! One thing though...

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, and will know 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 :)