Msbuild NUnit和NAnt的未来考虑

在.NETV1的日子里，我试图说服同事们使用NUnit和NAnt的其他工具开发测试驱动和自动构建工作习惯，但没有取得多大成功。当.NETFramework2.0和VisualStudio2005TeamSuite出现时，我能够“强制”我的团队编写测试，并在VisualStudio内部为他们自己提供可视化测试。我还可以使用额外的MSBuild任务调整项目文件，以实现更高的构建自动化

当然，这并不意味着微软已经提供了完美的系统，但我相信他们已经采取了正确的步骤。所有这些特性都直接融入到框架和产品中，并且变得“原生”，这使得开发人员更容易进入更好的开发实践

早就忘记了开源选项（我确实错过了），我想知道NUnit和NAnt的当前版本有什么价值主张？在这个阶段，您可以提出什么样的案例来说服团队不要使用MSBuild或MSTest

澄清：

---

我的公司是一家纯粹的微软SI。我们可以使用VisualStudioTeamSuite版本、数据库专业版、TFS等。我们不使用Visual Studio Professional edition或更低版本。

MSBuild是一个非常好的构建工具。我已经将它与NAnt和Cruisecontrol.Net结合使用过好几次了。NAnt和NAnt contrib扩展在处理诸如NUnit、NCover等OSS工具时似乎更灵活，而MSBuild可以构建VS解决方案这一事实对它来说是一个巨大的优势。我发现创建构建脚本最简单的方法是使用NAnt调用构建的不同部分（build、fxcop、test、coverage等）和MSBuild执行实际构建

---

关于MSTest我没什么好说的。例如，在构建服务器上进行安装既慢又麻烦。它不是很灵活，有各种各样的“额外功能”，似乎更适合集成测试而不是单元测试。我发现轻量级的XUnit.Net、MBUnit或NUnit更适合于单元测试。速度在这里很重要，您希望经常运行测试，以便快速反馈代码更改的效果。可移植性也很重要。您希望在没有安装team system的机器上运行测试，而无需进行大量的设置和黑客攻击。尽管单元测试并不新鲜，但仍有很多开发正在进行中。最佳实践和工具都有很大的变化。我不想被捆绑在一个工具上，这个工具在VisualStudio中每隔几年才升级一次。三个OSS.net单元测试工具中的每一个都被设置为可扩展的。MSTest不是（据我所知）。

在我看来，NUnit是.NET中单元测试的事实标准。它是免费的，您可以在任何版本的VisualStudio中轻松编写测试。如果微软在VS 2005 Pro中提供了MS测试（正如他们在VS 2008 Pro中所做的那样），它现在可能已经接管了——但我认为为时已晚

我认为ReSharper对于VisualStudio来说基本上是必不可少的，其中包括一个非常好的测试运行程序，它与NUnit配合得非常好。如果我正在开发一个开源项目，为什么我需要VS2008Pro或VS2005TeamSuite

MSBuild与NAnt略有不同，因为MSBuild与框架或SDK捆绑在一起（我现在不记得是哪一个了），但我认为NAnt是一个更适合工作的环境。MSBuild显然更适合于执行原始的“构建解决方案”位，但您可以从NAnt调用它