Unit Tests & access modifiers

  • Thread starter Thread starter Michael Bray
  • Start date Start date
M

Michael Bray

I've just inherited a fairly large project with multiple classes. The
developer also wrote a huge number of unit tests (using NUnit) to validate
that the classes work correctly. However, I don't think that the class
itself should include unit tests, especially since it has to reference
nunit.framework in order to compile/work, and I don't want to have to
distribute the nunit.framework.dll with this class.

So I created a new project, moved the folder with all the unit tests to the
new project, and referenced the original project. When I compiled, I found
that the reason they were in the original project in the first place was
because the unit tests test a whole bunch of 'internal' classes.

Is there any way that I can split the unit tests into a separate project
and still let the unit tests compile and run?

This is .NET 1.1 - I think I recall something that we could do in .NET 2.0,
but I need it in .NET 1.1 as well.

TIA!

-mdb
 
http://weblogs.asp.net/rosherove/archive/2004/07/10/179515.aspx
Click to expand...

Might have worked, if I could actually download the file referenced in the
article... :(

Any other suggestions? It would be impractical to use either of the other
two solutions in the article. To start with the #1 Alternate doesn't
remove the requirement of referencing nunit.framework.dll, which is the
whole point of it anyway. And #2 would be difficult since I have over 200
unit tests, each in a separate file!

-mdb
 
Michael said:
I've just inherited a fairly large project with multiple classes. The
developer also wrote a huge number of unit tests (using NUnit) to validate
that the classes work correctly. However, I don't think that the class
itself should include unit tests, especially since it has to reference
nunit.framework in order to compile/work, and I don't want to have to
distribute the nunit.framework.dll with this class.

So I created a new project, moved the folder with all the unit tests to the
new project, and referenced the original project. When I compiled, I found
that the reason they were in the original project in the first place was
because the unit tests test a whole bunch of 'internal' classes.

Is there any way that I can split the unit tests into a separate project
and still let the unit tests compile and run?

This is .NET 1.1 - I think I recall something that we could do in .NET 2.0,
but I need it in .NET 1.1 as well.

TIA!

-mdb
Click to expand...

In 2.0 you can use he InternalsVisibleTo Attribute which gives access to
all internal members of an assemblies.

In 1.1 you can take your UnitTests out in in your productional build
using conditional compilation.

BTW, even if you leave everything as it is, you don't have to deploy the
nunit.framework.dll. As long as nobody executes the test code the system
will not attemp to load it.

HTH,
Andy
 
Michael said:
I've just inherited a fairly large project with multiple classes. The
developer also wrote a huge number of unit tests (using NUnit) to validate
that the classes work correctly. However, I don't think that the class
itself should include unit tests, especially since it has to reference
nunit.framework in order to compile/work, and I don't want to have to
distribute the nunit.framework.dll with this class.

So I created a new project, moved the folder with all the unit tests to the
new project, and referenced the original project. When I compiled, I found
that the reason they were in the original project in the first place was
because the unit tests test a whole bunch of 'internal' classes.

Is there any way that I can split the unit tests into a separate project
and still let the unit tests compile and run?

This is .NET 1.1 - I think I recall something that we could do in .NET 2.0,
but I need it in .NET 1.1 as well.
Click to expand...

I would view it slightly different.

Does it make sense to unit test the internal stuff
in an assembly ?

I would say that you unit test the exposed public interface
and do not worry about the internal encapsulated implementation.

Arne
 
as long as the users didn't actually run any unit tests you would only have
to compile the solution against the framework, you wouldn't have to include
it in your distro
 
Back
Top