Quick & Dirty Compatibility


You say this new unit testing tool in VS Team System is something that you want to use but you have a large number of existing tests in NUnit. For some reason you don’t have a great desire to walk through and change all the attribute names. Well, based on a few responses to My first unit test in Visual Studio Team System entry you might not have to do that much. The gist of the replies suggested that you simply could substitute the NUnit attribute names with the VS Team System attribute names. I thought I would try this out on the StackFixture code that is part of Chapter 2 in my Test-Driven Development in Microsoft .NET book. Here is the code:


using System;


// using NUnit.Framework;
using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;
using TestFixture = Microsoft.VisualStudio.QualityTools.
   
UnitTesting.Framework.
TestClassAttribute;
using Test = Microsoft.VisualStudio.QualityTools.
   
UnitTesting.Framework.
TestMethodAttribute;
using SetUp = Microsoft.VisualStudio.QualityTools.
   
UnitTesting.Framework.
TestInitializeAttribute;


[TestFixture]
public
class StackFixture
{
   
private Stack
stack;

   
[SetUp
]
   
public void
Init()
   
{
       
stack = new Stack
();
   
}

   
[Test
]
    
public void
Empty()
   
{
       
Assert
.IsTrue(stack.IsEmpty);
   
}

   
[Test
]
   
public void
PushOne()
   
{
       
stack.Push(“first element”);
       
Assert
.IsFalse(stack.IsEmpty,
            “After Push, IsEmpty should be false”);
   
}

   
[Test
]
   
public void
Pop()
   
{
       
stack.Push(“first element”);
       
stack.Pop();
       
Assert
.IsTrue(stack.IsEmpty,
           
“After Push – Pop, IsEmpty should be true”);
   
}

    // tests 

   
[Test]
   
[ExpectedException
(typeof(InvalidOperationException))]
   
public void PopEmptyStack()
   
{
       
stack.Pop();
    
}

    // additional tests


}



All I had to do was comment out the using NUnit.Framework statement (part of me is in pain when I do this) and add the using statements for the various attributes and compile. The code compiles and when I run it all 14 tests pass. No changes to the code beyond the using statements. There are a few caveats, but it’s a start. I will be blogging more on issues with compatibility in the coming days.


This posting is provided “AS IS” with no warranties, and confers no rights.

Comments (10)

  1. Marc Clifton says:

    Is there some reason Microsoft chose to implement brain dead unit testing?

    What about http://aut.tigris.org/

    What about http://www.codeproject.com/gen/design/autp5.asp

    And why make unit testing available only for team test?

  2. Simon Hodd says:

    I used this method too (even throwing in an #ifdef so I can switch back and forth). But how do you handle the NUnit Ignore attribute?

  3. Mike says:

    Thats nice and reassuring, but really why did they choose to deviate from the base Attributes that everyone has been using. If they wanted to add functionality they could have just extended those.

  4. Convert existing NUnit test harnesses to VS Team System

  5. AT says:

    Instead of commention out you can use

    #ifdef VSNET

    using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;

    …..

    #else

    using NUnit.Framework

    #endif

    This way you will be able to work with both..

    But as I’ve found – Microsoft Assert class is more powerfull. You can not get backward compatibility from Microsoft Assert to NUnit one.

    As well you can use reverse code to use test classes generated by VS.NET in NUnit.

    This sounds better becouse Microsoft attribute names are readable instead of SetUp and TearDown ;o)

    #if VSNET

    using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;

    #else

    using TestMethod = NUnit.Framework.TestAttribute;

    using TestClass = NUnit.Framework.TestFixtureAttribute;

    using TestInitialize = NUnit.Framework.SetUpAttribute;

    using TestCleanup = NUnit.Framework.TearDownAttribute;

    #endif

Skip to main content