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

• Anonymous
  June 16, 2004
  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?
• Anonymous
  June 16, 2004
  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?
  
  
• Anonymous
  June 17, 2004
  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.
• Anonymous
  June 17, 2004
  Convert existing NUnit test harnesses to VS Team System
• Anonymous
  June 21, 2004
  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
  
  
  
• Anonymous
  May 31, 2009
  PingBack from http://indoorgrillsrecipes.info/story.php?id=4784