How to Ease TDD with MSTest / VS2008

Question

I've read time and time again that TDD/test first is more difficult with MSTest than it is with other testing frameworks such as nUnit, MBUnit, etc... What are some suggested manual workarounds and/or 3rd party bits that you suggest when MSTest is the only option due to infrastructure policy? I'm mainly wondering about VS 2008 Team Suite, but I suppose tips for VS 2008 Pro on up would be suitable too since some MSTest functionality is now included with those versions as well.

Answer 1

MSTest is certainly not as efficient or extensible as some of the open source frameworks, but it is workable. Since the question asks about making life easier with MSTest and not about alternatives, here are my MSTest tips.

• Shortcuts. Like Haacked said, take a few seconds to learn the shortcuts.
• Current Context. Since MSTest is so slow, run tests only in the current context when you can. (CTRL+R, CTRL+T). If your cursor is in a test method, this will only run the method. If your cursor is outside a method, but in a test class, this will only run the test. And with namespace, etc etc
• Efficient tests and organization. It's dog slow. Make things as best as you can by writing efficient tests. Move slow tests to other test classes or projects so you can run the fast tests more frequently.
• Testing with WCF. If you're testing services, be sure to DEBUG tests rather than RUN tests so Visual Studio can fire up the ASP.NET development web servers. After these are up, then you can go back to RUN, but it can be easier to just always DEBUG so you don't have to think about it.
• Config Files. Edit your test-run configuration to move .config files into the test execution folder.
• Integration with Source Safe. You need to be aware that MSTest hates SourceSafe and the feeling is mutual. Because MSTest wants to put test files under source control, and add them to the solution, it must check out the solution every time you run tests. So SourceSafe must be running in multi-check-out mode to avoid killing your fellow developers.
• Ignore the fluff With MSTest, you get a dozen different windows and views. Test Runs, Test View, Test Lists ... they're all less-than-helpful. Stick with Test Results and you'll be much happier.
• Stick with "Unit Tests". When you add a new test, you can add an ordered test, a unit test, or run through a wizard. Stick with just plain simple unit tests.

Answer 2

If you have no choice but to use MSTest, learn the keyboard shortcuts. They'll make your life a little easier.

Test in Current Context: CTRL+R, T
All Tests in Solution: CTRL+R, A

Debug Tests in Current Context: CTRL+R, CTRL+T
Debug All Tests in Solution: CTRL+R, CTRL+A

Answer 3

I've done TDD development using NUnit for a number of years and have been using MSTest for about 4 months now due to a role change.

I don't think that MSTest stops someone from doing TDD. You still have all the core things you need for TDD such as basic asserts and mocking frameworks (I use Rhino Mocks).

MSTest does integrate closely with Visual Studio, the best component of this integration is the Code Coverage Tool that is built in.

BUT There are a number of compelling reasons not to use MSTest. The two biggest turn offs in my opinion are:

1. The lack of assert options (compared to NUnit)
2. The sluggish test runner (slow compared to NUnit)

This means that writing asserts takes more code in combination with a slow test runner means that the whole process is slower than NUnit. The open source options also have a lot more support in the community.

If you are using TFS for CI, then you will need to jump through a few hoops/hacks to get NUnit to publish test results. Running tests on TFS with MSTest in comparison is very easy and straight forward. If you don't touch TFS than I'd go NUnit all the way, it's just nicer.

Answer 4

as mentioned oyu need to install the full IDE in order to use MSTest on another machine, which is a bit crap. I suppose this is because they want to make sure that unit tests only works on the higher end visual studios and you sholdné be able to run them in any other way.

ALso, MSTest is quite slow, this is because inbetween each test it rebuilds the entire context for each test, this makes o0ne sure that a former test - failed or otherwise doen't infuence the current test, but slows things down. you can however use the /noisolation flag, which will run all tests within the MSTest process - which is quicker. To speed up in IDE: In the VS ide you can go to Tools-Options then select Test Tools. Select sub-item called Test execution and in dialouge to the right make sure the check box called 'Keep test execution engine running between test runs' is checked.

Answer 5

I'm curious here. What I don't understand is that people start comparing all Open Source tools available with MSTest and start bashing it. Commenting on how unwieldy it is, how unintiuitve etc. IMHO, it's because it's fundamentally different from xUnit frameworks. It's optimized for parallel execution.

Even the qurik of having static ClassInitialze and Cleanup and having unique TestContext for each of the tests all because of the nextgen - at least for Windows business programmers in MS languages - parallel progarmming concepts.

I had the misfortune of working in a project with tens of thousands of unit tests. They used to take virtually most of the build time! With MSTest, we cut that down to very managable timelines.

Answer 6

• MSTest has "high friction": Getting a build script with NAant and MbUnit compared to MStest and MSBuild. No Comparison.
• MSTest is Slow MbUnit and NUnit are in my experince faster (gallio may help here)
• MStest adds a bunch of stuff i dont need like wired config files etc.
• MSTest doesnt have the fetaure set of other OS test frameworks. check out xUnit and MbUnit

It just too hard to use and there are many better options.

Answer 7

My colleague Mike Hadlow has pretty good summary of why we utterly loath MSTest here.

He's managed to remove it from his project, but I'm currently working on a larger project with more politics involved so we're still using it.

The upshot of it is that whoever implemented MSTest doesn't understand TDD. I'm sorry to sound like an M$ basher - I'm really not. But I'm annoyed that I'm having to put up with a very poor tool.

Answer 8

To answer a non-pointed question, my answer would be "probably NUnit just stays out of your face."

Disclaimer: I've no actual experience with MS version of xUnit, however I hear problems like 'You need to install the gigantic idea just to run your tests on a separate machine' - which is a complete No-No. Other than that MS has this way of contorting the right path for a newbie via some kind of IDE bell/whistle that runs counter to the whole idea. Like generating tests from classes was one I remember from a year or so back.. that defeats the whole point of test-driving - your design is supposed to emerge from tiny steps of RGR: writing a test-make it pass-refactor. If you use that tool - it robs you of the entire experience.

I'll stop with my sermon.. now :)

Answer 9

There are lots of config files with mstest, making it less condusive.
Another reason I chose mbunit, is the "rollback" feature of mbunit. This allows you to rollback all database things done in this test, so you can actually do full circuit tests and not worry about the pond being tainted after the test.
Also lack of RowTest facilities in mstest.

I suggest just running mbunit as a dependency inside the build process, its easy enough to just float it with your bin, and reference, no installation required.

Answer 10

I have not seen any serious issues with MSTest. What, specifically, are you talking about? We are, in fact, moving away from NUnit to MSTest. I do not know our reasons for this, though.