Derik Whittaker

How to do this with MSTest.

1.  In Solution Explorer, right-click the Solution (not the Project).

2.  Click Add, New Item

3.  In Categories, select Test Run Configuration

4.  Now choose the Test Run Configuration item and add it to your project

5.  In Solution Explorer, double-click the Test Run Configuration you just created

6.  Click the Deployment item

7.  Add your config file as a deployed file (or deploy the entire folder which contains it, if appropriate)

This took me a little while to figure out, but I'm in a similar situation and it does work for me.

It copies things to the oddly named folders because on that instance of running the test, those are exactly the files being tested, plus that is where it puts all of the logs, reports, and whatnot.

I have to use MSTest as it is a org standard but it suxs

so with this code

#if NUNIT

using TestClass = NUnit.Framework.TestFixtureAttribute;

using TestMethod = NUnit.Framework.TestAttribute;

using TestCleanup = NUnit.Framework.TearDownAttribute;

using TestInitialize = NUnit.Framework.SetUpAttribute;

using ClassCleanup = NUnit.Framework.TestFixtureTearDownAttribute;

using ClassInitialize = NUnit.Framework.TestFixtureSetUpAttribute;

using Assert = NUnit.Framework.Assert;

#else

using Microsoft.VisualStudio.TestTools.UnitTesting;

#endif

and a little project/solution config and a compilation constant i can use nunit on my machine but other people can still use MSTest on their machines.

@Derik

Are talking about the “Assert.That” syntax?

If so since these eventually throw an exception (NUnit.Framework.AssertionException in this case) you can us nunits assert from mstest (or the other way around).

So perhaps the usings should be

#if NUNIT

using TestClass = NUnit.Framework.TestFixtureAttribute;

using TestMethod = NUnit.Framework.TestAttribute;

using TestCleanup = NUnit.Framework.TearDownAttribute;

using TestInitialize = NUnit.Framework.SetUpAttribute;

using ClassCleanup = NUnit.Framework.TestFixtureTearDownAttribute;

using ClassInitialize = NUnit.Framework.TestFixtureSetUpAttribute;

#else

using Microsoft.VisualStudio.TestTools.UnitTesting;

#endif

using NUnitAssert = NUnit.Framework.Assert;

using MsAssert = Microsoft.VisualStudio.TestTools.UnitTesting.Assert;

I don't see the big problem... I'd never used a test framework before MSTest and I spent maybe 10 minutes googling for the answer (read first comment from Craig). Not a big deal, IMO.

There are other far worse issues that I'm having; specifically when I debug a test... Now that is bad. This is just peanuts IMO.

I had a similar problem using MSTest for integration tests of a CAB application. CAB looked in the BaseDirectory which MSTest set as "C:\\Program Files\\Microsoft Visual Studio 9.0\\Common7\\IDE\\" Whereas in reality it should look in the current Directory.

to get around this I put a nasty hack in the test:

AppDomain.CurrentDomain.SetData("APPBASE", Environment.CurrentDirectory);

Be careful to set it back afterwards otherwise your other tests may be affected

Pingback from  Dew Drop - July 24, 2008 | Alvin Ashcraft's Morning Dew

The default directory is a bug in VS2008.  In VS2005 it worked correctly...set this in you class initialize (MyClassInitiaize or whatever the code generate method is)...

AppDomain.CurrentDomain.SetData("APPBASE", Environment.CurrentDirectory)

The folders are created so that at anytime you can pull up a previous test run to view the DLL's as they were at the time of the test and what tests passed or failed.   Very handy if you work on a legacy app like mine and need to go back a few days to see what some junior programmer changed in order to figure out why a test failed today that you can now show passed 2 days ago.

Yes, I had a lot of problems with MsTest the first times I was testing custom configuration sections and the alike. But once you figure out what it going on (and it's a lot, that's why it is soooo slow) you are fine.

@Brian

I think they use that strategy to have some sort of "isolation" between test run. In order to find out why code is broken I think you are better off using SCM...

Developer Friction is Relative

Just use NUnit and TestDriven.NET, that's ALL YOU NEED.

Goto to the testconfig and select user-defined scheme.

At prefix text: type TestDir

Uncheck Append date-time stamp.

In the pre-build event command line of the test project

use the following line

RD "..\..\..\TestResults"  /q /S

Now the test will always build to testresults\testdir

Have fun

Constantijn

FYI...I hate MSTest too, but the issue of the base directory being "C:\\Program Files\\Microsoft Visual Studio 9.0\\Common7\\IDE\\" was introduced in VS2008 but fixed in VS2008 SP1.

It took me hours today before I'd discovered it was a bug and SP1 fixed it...