unit test best practice

[Droopy]

Hi,

I want to add unit tests in my application using NUnit.
At first, I thought to add unit tests in the class that is tested, enclosed
in a conditional attribute to remove these unit tests from release code.
Though, there is (at least) 2 problems working like that :

1) the class can becoming very large if there is a lot of tests
2) when releasing, the NUnit dll should not be needed => it should not be
referenced.

How do you manage this ?

Thanks in advance for your help.

[Mark R. Dawson]

Hi Droopy,
when writing your unit tests put them inside a seperate project and
reference the libraries you want to test from your test project. This way
your test project will have a reference to the NUnit.Framework DLL and will
contain all of your testing code, your production project will then have no
code relating to testing or any unneccessary references.

For each class you want to test i.e. MyLibrary.MyObject you would have a
corresponding test fixture in your testing project i.e.
MyTestingProject.MyObjectTestFixture
Hope that helps
Mark R Dawson
http://www.markdawson.org

Some of my thought on unit testing
http://www.markdawson.org/software/unittesting

"Droopy" wrote:

Hi,

I want to add unit tests in my application using NUnit.
At first, I thought to add unit tests in the class that is tested, enclosed
in a conditional attribute to remove these unit tests from release code.
Though, there is (at least) 2 problems working like that :

1) the class can becoming very large if there is a lot of tests
2) when releasing, the NUnit dll should not be needed => it should not be
referenced.

How do you manage this ?

Thanks in advance for your help.

[Oliver Sturm]

Droopy wrote:

I want to add unit tests in my application using NUnit.
At first, I thought to add unit tests in the class that is tested, enclosed
in a conditional attribute to remove these unit tests from release code.
Though, there is (at least) 2 problems working like that :

1) the class can becoming very large if there is a lot of tests
2) when releasing, the NUnit dll should not be needed => it should not be
referenced.

How do you manage this ?

I use separate assemblies for my unit tests, usually one per
implementation assembly. These assemblies reference the tested assembly,
the NUnit assembly and everything else needed for the purpose of testing.

Of course it can be a bit difficult to access object properties or methods
that aren't publicly available in such a scenario, but I tend to believe
that it's not usually the best idea to test non-public members at all. For
those instances where it seems to be a good idea, I have my own
"PrivateObject" implementation, a class that wraps another class and
allows access to non-public members - in VS 2005, AFAIK, there's a similar
thing readily available and you can also use InternalsVisibleTo attribute
to allow your testing assembly access to stuff inside the implementation
assembly.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[TaylorMichaelL]

I agree with the other posters. I keep my testing code separate from the
actual release code. I actually keep the testing code in a parallel solution
with parallel projects as my release code to make things easier. One thing I
did want to point out is that just because you reference an assembly doesn't
mean it'll actually be loaded. .NET assemblies work the same as delay-loaded
DLLs. A .NET assembly will only be loaded when an object contained in the
assembly is needed so unless you reference a test object NUnit doesn't need
to be shipped although it will, by default, be copied to your deployment
directory when you build it in VS. Still I don't like having any "excess"
references so keep your test projects separate from your release projects.
Note however that VS 2005 will automatically add a test project to your
solution when you elect to auto-generate test cases for a class. You'll then
need to move the project elsewhere.

Michael Taylor - 9/5/05

"Droopy" wrote:

Hi,

I want to add unit tests in my application using NUnit.
At first, I thought to add unit tests in the class that is tested, enclosed
in a conditional attribute to remove these unit tests from release code.
Though, there is (at least) 2 problems working like that :

1) the class can becoming very large if there is a lot of tests
2) when releasing, the NUnit dll should not be needed => it should not be
referenced.

How do you manage this ?

Thanks in advance for your help.

[Droopy]

OK thanks for your answer.

I was just creating separate assemblies that reference the tested
assembly and NUnit assembly.
The only problem left is with the main GUI application that is a .exe
file => it cannot be referenced by the test assembly.
May be it is not a good idea to test the GUI ?
Ideally, perhaps I should use interfaces between GUI and "business
logic" code and only test these interfaces ?
"Oliver Sturm" <ol****@sturmnet.org> wrote in
news:xn****************@msnews.microsoft.com:

Droopy wrote:

I want to add unit tests in my application using NUnit.
At first, I thought to add unit tests in the class that is tested,
enclosed in a conditional attribute to remove these unit tests from
release code. Though, there is (at least) 2 problems working like that
:

1) the class can becoming very large if there is a lot of tests
2) when releasing, the NUnit dll should not be needed => it should not
be referenced.

How do you manage this ?

I use separate assemblies for my unit tests, usually one per
implementation assembly. These assemblies reference the tested
assembly, the NUnit assembly and everything else needed for the
purpose of testing.

Of course it can be a bit difficult to access object properties or
methods that aren't publicly available in such a scenario, but I tend
to believe that it's not usually the best idea to test non-public
members at all. For those instances where it seems to be a good idea,
I have my own "PrivateObject" implementation, a class that wraps
another class and allows access to non-public members - in VS 2005,
AFAIK, there's a similar thing readily available and you can also use
InternalsVisibleTo attribute to allow your testing assembly access to
stuff inside the implementation assembly.
Oliver Sturm

[Oliver Sturm]

Droopy wrote:

I was just creating separate assemblies that reference the tested
assembly and NUnit assembly.
The only problem left is with the main GUI application that is a .exe
file => it cannot be referenced by the test assembly.
May be it is not a good idea to test the GUI ?
Of course this is just a personal preference, but I like to have all the
code that does more than just glue together other parts in a DLL assembly.
The glue code in the final EXE assembly that makes up the application
would be quite hard to test with NUnit, I believe, and in this way I get
to use unit tests for allmost all parts of my code.

I do use AutomatedQA's TestComplete to test gui stuff, though.
Ideally, perhaps I should use interfaces between GUI and "business
logic" code and only test these interfaces ?

Yes, I think that's what you should do.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Droopy]

"Oliver Sturm" <ol****@sturmnet.org> wrote in
news:xn****************@msnews.microsoft.com:

Droopy wrote:

I was just creating separate assemblies that reference the tested
assembly and NUnit assembly.
The only problem left is with the main GUI application that is a .exe
file => it cannot be referenced by the test assembly.
May be it is not a good idea to test the GUI ?

Of course this is just a personal preference, but I like to have all
the code that does more than just glue together other parts in a DLL
assembly. The glue code in the final EXE assembly that makes up the
application would be quite hard to test with NUnit, I believe, and in
this way I get to use unit tests for allmost all parts of my code.

I do use AutomatedQA's TestComplete to test gui stuff, though.

Ideally, perhaps I should use interfaces between GUI and "business
logic" code and only test these interfaces ?

Yes, I think that's what you should do.
Oliver Sturm

OK thanks for your time.