471,594 Members | 1,656 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,594 software developers and data experts.

Unit Tests & access modifiers

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
Oct 27 '06 #1
6 1903
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
Oct 27 '06 #2
"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
Oct 27 '06 #3
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
Oct 27 '06 #4
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
Oct 28 '06 #5
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

Oct 29 '06 #6
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

Oct 29 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Hugh Cowan | last post: by
6 posts views Thread by Tom Verbeure | last post: by
14 posts views Thread by | last post: by
6 posts views Thread by Droopy | last post: by
3 posts views Thread by Diego Park | last post: by
72 posts views Thread by Jacob | last post: by
5 posts views Thread by shuisheng | last post: by
6 posts views Thread by Vyacheslav Maslov | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.