Unit Tests & access modifiers

[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

[ssamuel]

Michael,

This may help:

http://weblogs.asp.net/rosherove/arc...10/179515.aspx

Stephan

Michael Bray wrote:

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

[Michael Bray]

"ssamuel" <ss*****@gmail.comwrote in news:1161976537.359560.64900
@b28g2000cwb.googlegroups.com:

http://weblogs.asp.net/rosherove/arc...10/179515.aspx

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

[Martin Z]

Well, there's always the controversial idea that
http://c2.com/cgi/wiki?MethodsShouldBePublic

in short - if the method doesn't violate the class invariant, why not
make it make it public? And if it does, are you sure you want that
landmine lying around?

Michael Bray wrote:

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

[Andreas Mueller]

Michael Bray wrote:

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

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
--
You can email me directly by removing the NOSPAm below
xm**********@gmxNOSPAm.netNOSPAm

[Arne Vajhøj]

Michael Bray wrote:

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.

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

[CuriousGeorge]

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

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcomwrote in message
news:Xn****************************@207.46.248.16. ..

"ssamuel" <ss*****@gmail.comwrote in news:1161976537.359560.64900
@b28g2000cwb.googlegroups.com:

> http://weblogs.asp.net/rosherove/arc...10/179515.aspx

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