Monday, August 13, 2007

I have been using VSTSTest on my current project for around 6 months now and I find that it causes a lot of pain and it has a lot of hacky quirks. I'm not the only one the doesn't like it.

I have decided to see how much effort it would take to switch to an MbUnit/NCover combination here at work.

Using ReSharper I first analyze usages of the Microsoft.VisualStudio.TestTools.UnitTesting namespace. 108 usages, it's everywhere! :(

The first step is going to be to change all of the attributes from the VSTS [TestClass] and [TestMethod]. If Microsoft would have named these according to all the other unit testing suites that came before it I could've skipped this step. Here are the attributes I had to change:

VSTS Attribute MbUnit Attribute
[TestClass] [TestFixture]
[TestInitialize] [SetUp]
[TestCleanup] [TearDown]
[TestMethod] [Test]
[DeploymentItem] Change the resource to copy to the output dir

 

The next problem that I came across was that our team had a bunch of tests that were testing private methods. For those that don't know VSTSTest generates a file called VSCodeGenAccessors in your test project when you (sigh) right click on a private method and select Create Private Accessor. MbUnit has the ability to test private methods so I had to change all of the tests that used the private method testing to use the MbUnit equivalent:

Reflector.Invoke(objectUnderTest, "PrivateMethod", "parameters");

Now, I am in a compiling state! I run the tests and they all pass. I am free of the shakles!

Monday, August 13, 2007 10:54:03 PM (GMT Standard Time, UTC+00:00)  #    Comments [5]  | 
Tuesday, August 14, 2007 1:55:26 AM (GMT Standard Time, UTC+00:00)
MbUnit == good. I like it. If I may ask, why are you testing private methods?
Tuesday, August 14, 2007 5:41:18 AM (GMT Standard Time, UTC+00:00)
Tom,
Well to be honest, we are testing them because the feature is there. We are probably wasting our time testing both the private methods and the public methods that call into them. This is probably a good time to rework the tests.
Tuesday, August 14, 2007 1:04:34 PM (GMT Standard Time, UTC+00:00)
Well, to be honest, it's kind of odd to test the private methods - I never do it. If I feel that a private method needs a unit test I take that as a sign that I've got some refactoring to do or that maybe the method should be public.
Thursday, August 16, 2007 6:54:18 PM (GMT Standard Time, UTC+00:00)

Yes, I am in the same situation. I have about 48 unit test methods per class file and now I have to paste DeploymentItem for each of them. Nice!
Sergey Malgin
Thursday, August 16, 2007 7:14:59 PM (GMT Standard Time, UTC+00:00)
Sergey,

If you are using one, you can add items to the *.testrunconfig file in your solution so you don't have to add the DeploymentItem attribute to every test method that needs it. This won't work however if you run the tests from the command line unless you specify the testrunconfig file using the /runconfig flag.
Comments are closed.

Theme design by Jelle Druyts

Pick a theme: