By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,247 Members | 1,273 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,247 IT Pros & Developers. It's quick & easy.

EXCLUDE nunit from production release

P: n/a
It is great to have an automated testing during development.

BUT,

How can I build the production release without nunit being included?

THX.

John
p.s. I posted this in nunit group but seems there are not much activity
there.

Jun 21 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Put your tests in a seperate test assembly.
Q. John Chen wrote:
It is great to have an automated testing during development.

BUT,

How can I build the production release without nunit being included?

THX.

John
p.s. I posted this in nunit group but seems there are not much activity
there.


Jun 21 '06 #2

P: n/a
I also need to test "internal" classes.

Jun 21 '06 #3

P: n/a
I would still put the tests in a separate assembly, and use reflection
to create instances and call methods/properties, etc, etc that you need.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Q. John Chen" <qj****@email.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
I also need to test "internal" classes.

Jun 21 '06 #4

P: n/a
On 21 Jun 2006 07:38:52 -0700, "Q. John Chen" <qj****@email.com>
wrote:
It is great to have an automated testing during development.

BUT,

How can I build the production release without nunit being included?

THX.

John
p.s. I posted this in nunit group but seems there are not much activity
there.


While keeping the test code in a seperate assembly is the recommended
way, it is pretty easy to do it in one assembly.

Just use the #if statement like this.

#if DEBUG

public class TestCode
{
//
}

#endif
Note, that the NUnit dlls will still be included in the build, but
removing them manually (or not including them in the setup) works
fine. Unless the JIT compiler actually needs the dlls, it won't miss
them.

A somewhat nicer alternative is to place all NUnit specific code in
another assembly, and only place the minimal amount of test code that
is needed to call internal/private methods inside the code assembly
(That test code should still be surrounded by #if DEBUG though). It is
a good compromise in my opinion, unless you want to use reflection to
do tests.

--
Marcus Andrén
Jun 21 '06 #5

P: n/a
"Marcus Andrén" <a@b.c> wrote in message
news:a3********************************@4ax.com...
A somewhat nicer alternative is to place all NUnit specific code in
another assembly, and only place the minimal amount of test code that
is needed to call internal/private methods inside the code assembly
(That test code should still be surrounded by #if DEBUG though). It is
a good compromise in my opinion, unless you want to use reflection to
do tests.


That's an interesting idea. The only problem I have with using #if DEBUG is
that it means you're shipping different code than you're testing.

///ark
Jun 21 '06 #6

P: n/a
Marcus Andrén <a@b.c> wrote:
While keeping the test code in a seperate assembly is the recommended
way, it is pretty easy to do it in one assembly.

Just use the #if statement like this.

#if DEBUG

public class TestCode
{
//
}

#endif


Don't forget the handiness of the [Conditional("DEBUG")] attribute
either. Calls to methods marked with this that don't return a value get
removed from the compiled version etc.

-- Barry

--
http://barrkel.blogspot.com/
Jun 21 '06 #7

P: n/a
I was thinking of three configuration:
Debug, with nunit,
Release, with nunit,
and
ProductionRelease, w/o nunit.

This way, I am still shipping the same code except with the tests
removed. And I don't need to shipping the nunit dll either.

THX

Jun 21 '06 #8

P: n/a
Q. John Chen wrote:
I also need to test "internal" classes.


Some would argue that you don't need to test internal classes, because
you only want to make sure your public API doesn't change.

I'm not one of those though...

If you're using .Net 2.0, you can use the InternalVisibleTo assembly
attribute in your code assembly, to allow the test assembly to see
internals.

If not, I'm not sure the best way to proceed.

Jun 22 '06 #9

P: n/a
"Andy" <aj*****@alum.rit.edu> wrote in message
news:11**********************@b68g2000cwa.googlegr oups.com...
If you're using .Net 2.0, you can use the InternalVisibleTo assembly
attribute in your code assembly, to allow the test assembly to see
internals.


OMG, C# has friends!!

(It's actually InternalsVisibleTo)

///ark
Jun 22 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.