During .NET v1 days, I have tried without much success to convince colleagues to develop test-driven and automated-build work habits using the additional tools of NUnit and NAnt. When .NET Framework 2.0 and Visual Studio 2005 Team Suite came into picture, I was able to "force" my team into writing tests and provide themselves with visual testing right inside Visual Studio. I was further able to tweak project files with extra MSBuild tasks to carry out more build automation.
Of course this does not mean Microsoft has delivered perfect systems, but I believe they have taken these in the correct steps forward. With all these features baked right into the framework and products and becoming "native" it got abit easier to motion developers into better development practices.
Having long forgotten the open-source options (which I do miss), I am wondering what value proposition do the current incarnations of NUnit and NAnt hold? What case can one argue at this stage to convince a team not to use MSBuild or MSTest?
Clarification:
My company is a pure Microsoft SI. Visual Studio Team Suite editions, Database Professional edition, TFS, and the like are available for our use. We do not use Visual Studio Professional edition or lesser.
Best Answer
MSBuild is a pretty good build tool. I've used it in combination with NAnt and Cruisecontrol.Net a couple of times. NAnt together with the NAnt contrib extensions seems a bit more flexible in handling OSS tools like NUnit, NCover etc while the fact that MSBuild can build VS solutions is a big plus for it. I found the easiest way to create build scripts is to use both, NAnt to call the different parts of the build (build, fxcop, test, coverage etc) and MSBuild to do the actual building.
I haven't got much good to say about MSTest. It's slow and cumbersome to install on for example a build server. It's not very flexible and has all kinds of 'extras' that seem more geared to integration testing than unit testing. I found light weight XUnit.Net, MBUnit or NUnit to be far better suited for unit testing. Speed is important here, you want to run the tests often for quick feedback on the effects of your changes in code. Portability is important too. You want to have the tests run everywhere without a lot of setup and hacking like you need for MSTest on a machine that doesn't have team system installed. Although Unit testing isn't new there's still a lot of development going on there. Best practices change a lot and so do the tools. I don't want to be tied to a tool that only gets upgraded every few years with visual studio. Every one of the three OSS .net unit testing tools is set up to be extensible. MSTest isn't (as far as i've seen).