unit test best practice

D

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

Guest

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
 
D

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 ?
 
O

Oliver Sturm

Droopy said:
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
 
D

Droopy

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.


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


Oliver Sturm

OK thanks for your time.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top