Unit testing in VSTS: Good and bad

With Scott's suggestion, I decided to install a newer build of Visual Studio 2005, namely the one with Team System in it. I had been using the older beta 1 just because I wasn't really using VS 2005 much anyway since finishing my book. I was most interested in the unit testing, and Scott's suggestion that the testing framework ran in an ASP.NET context. Here are my impressions thus far:

Good:
  • Configuration just works. I copied the would-be web.config to app.config in the test project and the tests had no problem getting data.
  • No need to leave Visual Studio.
Bad:
  • Test attribute names changed from NUnit. Stupid. I can't think of a single good reason for this.
  • Looking at the stack trace from a failed test doesn't let you click a code line number the way you do on a failed build to go right there. Right-click -> Go to source code sends you to the test code from the trace, which is almost never the real source of the error.
  • The UI in the test explorer kind of blows. NUnits did this better. I tend to group my tests in a class that tests a class, and I like to be able to test just that test class. You can group the tests by class, but then there's no box to check for just that class.
  • Assert.AreEqual fails. Expected: <1>, Actual: <1>. Huh?
  • If there's a way to test in a Web context, I don't know how to do it. As per my last post, I don't know I can test to see if Server.MapPath("~/whatever") will work.
  • If there's an obvious way to attach the debugger to the testing framework, that isn't obvious either.
Honestly if I could figure out those last two points, I'd be sold. I realize it's beta software, of course, but the documentation out in the world is kind of thin right now. A gold star to anyone that can fix those last two problems. :)

4 Comments

  • I honestly gave my best try to use built in testing in Dec CTP on a project. UI is simply horrible and terribly slow. I agree with you 100% on every point.



    I had this issue as well

    Assert.AreEqual fails. Expected: &lt;1&gt;, Actual: &lt;1&gt;



    If i remember correctly it was caused by enums.



    I'm also very annoyed by the AreEqual&lt;&gt; syntax. Why add more typing? In the end it's still going to call Object.Equals(). Pointless extra work IMO.

  • I'm not sure what build you are using, but in current builds you absolutly can debug inside of a test. In the newer builds you just right click inside of a test method signature and select (something like) debug this test.



    hth,

    Paul

  • What &quot;edition&quot; of VS do you have to have to get access to testing tools or is it included with all editions?

  • Or to debug all the tests you just use Test -&gt; Start Selected Test Project with Debugger.



    The UI does take a bit to get used to - it took me half an hour just to figure out how to enable Code Coverage and the number of times I wished I could do 2 (go straight to a failure).



    Apart from that, I think it rocks!

Comments have been disabled for this content.