are there guidlines for NUnit friendly classes?

[Julia]

Hi,

We are going to invest in testing and I wonder are there any guidelines
to design NUnit friendly classes?
Should I consider at all ease of use in unit testing when designing my
classes?

Thanks in advance.

Note that I am using NUnit to test my classes I am not doing TDD for now.

 

[Nicholas Paldino [.NET/C# MVP]]

Julia,

As long as you can call the methods on your classes somehow (and
configure the environment so that you can make the calls), then you
shouldn't have a problem.

Your NUnit tests are not coded into your classes (well, they could, but
they shouldn't). Rather, you should have separate classes which are your
test cases and then they call your classes you are trying to test.

Hope this helps.

 

[Julia]

Wow it was fast...

Thanks.

Julia,

As long as you can call the methods on your classes somehow (and
configure the environment so that you can make the calls), then you
shouldn't have a problem.

Your NUnit tests are not coded into your classes (well, they could, but
they shouldn't). Rather, you should have separate classes which are your
test cases and then they call your classes you are trying to test.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

We are going to invest in testing and I wonder are there any guidelines
to design NUnit friendly classes?
Should I consider at all ease of use in unit testing when designing my
classes?

Thanks in advance.

Note that I am using NUnit to test my classes I am not doing TDD for now.

 

[Bruce Wood]

Yes, you should consider ease of testing when you design your classes.

One thing you should think about is whether you can design classes that
you can decouple from the environment they run in.

For example, we have a business layer that calls a data layer to fetch
data from the database. However, I specifically designed the business
layer so that you could (using static properties and methods) "plug in"
a phoney data layer. That way I can write NUnit tests that create
phoney data layer objects to return canned data, "plug" them into the
business layer, then test the business layer. I do this because trying
to coordinate NUnit tests with "test" databases and "test" XML files,
and other "test" environments is a royal headache.

Ideally, you will have classes that do not in any way rely on
databases, files, or other environmental items or resources. However,
as in the case of my business layer, that's not always possible, so at
least provide a "back door" through which you can feed phoney data.

If you manage this, then the goal is to make your (NUnit testable)
business layer classes fat and your (difficult to test) data access and
UI layer classes as thin as possible. This maximizes your easy-to-test,
environment-independent logic and minimizes your difficult-to-test,
environment-dependent logic.