Unit testing

[Pete]

Hi folks,

I've been looking at unit testing frameworks (csUnit, NUnit, etc) and have
gathered some info on them (see the older thread on c# 2004). My question is
this: how do they work with windows forms?

All the samples I've seen are for trivial testing, such as making sure a
property sets it's value correctly. How would I go about testing, for
example, a custom control? All my testing seems to be visual (i.e. compile,
run, see if it looks okay).. am I missing something?

It seems to me that unit testing frameworks are of little use here.

Pete

 

[William Stacey]

http://www.nunit.org/default.htm is free and pretty good. And you can
write your test cases in c# which is natural.

 

[Pete]

Hi,

http://www.nunit.org/default.htm is free and pretty good. And you
can write your test cases in c# which is natural.

Did you actually read my message (I mentioned nunit)? My problem is how to
add test cases to windows forms controls (custom controls of my design) in a
useful way.

All the unit testing frameworks (for c#) work in virtually the same way.
NUnit is not unique, or even necessarily the best. Coupled with the fact
that their website seems to completely lack any info on typical/advanced
usage patterns, that link is not too useful to me.

-- Pete

 

[Arild Fines]

Hi folks,

I've been looking at unit testing frameworks (csUnit, NUnit, etc) and
have gathered some info on them (see the older thread on c# 2004). My
question is this: how do they work with windows forms?

All the samples I've seen are for trivial testing, such as making
sure a property sets it's value correctly. How would I go about
testing, for example, a custom control? All my testing seems to be
visual (i.e. compile, run, see if it looks okay).. am I missing
something?

It seems to me that unit testing frameworks are of little use here.

The general idea is to put as little actual functionality in the GUI layer
as possible. Instead factor out the "meat" of the application into separate
classes which have no knowledge of the GUI layer. These classes can then be
tested using a unit testing framework.

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi William (fellow MVP I suppose?),

Well it can still be usefull. A form is just a class right. You can't test
the visual look of the form easily, but you can test its function. You can
create an instance of a form, plug in test data or set control values, hit
buttons and read results from text boxes, etc. So you can test form
function and exceptions, and if things are visable or other properties on
the form/controls, etc.

A form is not just a class - it is also a window and therefore requires a
message pump to work. To the best of my knowledge, the message pump is
implemented in the Application class, so you will probably need to
instantiate one to run a form as a form and as not just a class.

 

[Pete]

Hi,

The general idea is to put as little actual functionality in the GUI
layer as possible. Instead factor out the "meat" of the application
into separate classes which have no knowledge of the GUI layer. These
classes can then be tested using a unit testing framework.

Hmm.. I've started using fxcop (which noone pointed out) and it works quite
well. As for unit test, the benefits here seem dwarfed by the effort
involved (my controls are mostly visual, certainly not enough "meat" to
warrant a separate class) so I think I'll pass.

-- Pete