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 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.

[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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Q. John Chen" <qj****@email.c om> wrote in message
news:11******** **************@ g10g2000cwb.goo glegroups.com.. .

I also need to test "internal" classes.

[Marcus Andrén]

On 21 Jun 2006 07:38:52 -0700, "Q. John Chen" <qj****@email.c om>
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

[Mark Wilden]

"Marcus Andrén" <a@b.c> wrote in message
news:a3******** *************** *********@4ax.c om...

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]

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("DE BUG")] 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/

[Q. John Chen]

I was thinking of three configuration:
Debug, with nunit,
Release, with nunit,
and
ProductionRelea se, 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]

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 InternalVisible To 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]

"Andy" <aj*****@alum.r it.edu> wrote in message
news:11******** **************@ b68g2000cwa.goo glegroups.com.. .

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

OMG, C# has friends!!

(It's actually InternalsVisibl eTo)

///ark