EXCLUDE nunit from production release

[Q. John Chen]

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.

 

[Andy]

Put your tests in a seperate test assembly.

 

[Q. John Chen]

I also need to test "internal" classes.

 

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

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.

 

[Marcus Andrén]

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.

 

[Mark Wilden]

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

 

[Barry Kelly]

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

 

[Q. John Chen]

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

 

[Andy]

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.

 

[Mark Wilden]

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