Re: Weird unit testing bug?

>> Here's an interesting conundrum for you:
>> 
>> I've written a bunch of unit tests that test a public method on an 
>> internal class located in another assembly, using some good ol'
>> fashioned reflection voodoo. Running these tests in VS2005 using 
>> TestDriven.NET 2.0.1438d and NUnit 2.4.3, these tests run just fine 
>> (although if I try to test with code coverage using NCover 1.4.0.7 it

>> refuses). For good measure, I also run the same tests using Resharper

>> 2.5, and they pass. So far, so good.
>> 
>> If I then drop out of Visual Studio, and fire up my NAnt scripts to 
>> repeat those tests, they fail. If I load up the NUnit GUI to repeat 
>> those tests, they fail. It's only the reflection-based tests that
fail 
>> - I've added some vanilla tests in there to make sure that 
>> setup/teardown calls were working OK, and those tests work just fine.
>> 
>> So, anyone have any idea why tests using reflection run fine when run

>> from within VS2005, but fail when run from the command line?

>Can you get this down to a simple test case and submit a bug report?

After a lot of trial and error, I've narrowed down the cause of my
problems. When I run from NAnt or NUnit GUI, I'm using a .nunit project
file, which loads some five test assemblies. Under these circumstances,
the tests fail. However, if I load the failing test assembly alone, then
the tests pass just fine. 

I wonder if we're not using the .nunit file in the correct way? In our
solution, we have a /test folder off the solution directory. Inside that
folder, is one folder per test project. Each test project has its own
config files which get copied into the /test folder as part of the build
process. However, the .nunit file only references one of these config
files. We don't set ApplicationBase, and have PrivateBinPath set to "Use
automatically generated path". I'll go away and read the documentation a
little more closely and experiment with the settings.

If I still can't figure it, I'll probably ditch the .nunit project and
just specify the test assemblies manually.
--
David Keaveny
Developer, Enterprise Applications, Fairfax Digital

P.S. Sorry about the huge disclaimer our mail systems tack on to the end
of all outbound emails!

The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attache
 d files.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php