msbuild - NUnit 和 NAnt 的 future 考虑因素

Question

在 .NET v1 期间，我曾尝试说服同事使用 NUnit 和 NAnt 的附加工具养成测试驱动和自动化构建的工作习惯，但没有取得多大成功。当 .NET Framework 2.0 和 Visual Studio 2005 Team Suite 出现时，我能够“强制”我的团队编写测试并在 Visual Studio 中为自己提供可视化测试。我还能够使用额外的 MSBuild 任务来调整项目文件，以实现更多的构建自动化。

当然，这并不意味着微软已经提供了完美的系统，但我相信他们已经采取了正确的步骤。通过将所有这些功能直接融入到框架和产品中并成为“ native ”，可以更轻松地插入开发人员采取更好的开发实践。

我早已忘记了开源选项(我确实怀念)，我想知道 NUnit 和 NAnt 当前的版本持有什么值(value)主张？在现阶段，可以通过哪些案例来说服团队不使用 MSBuild 或 MSTest？

澄清:我的公司是纯粹的 Microsoft SI。 Visual Studio Team Suite版本、Database Professional版本、TFS等可供我们使用。我们不使用 Visual Studio Professional 版本或更低版本。

Answer 1

MSBuild 是一个非常好的构建工具。我已经将它与 NAnt 和 Cruisecontrol.Net 结合使用了几次。 NAnt 与 NAnt contrib 扩展一起在处理 NUnit、NCover 等 OSS 工具方面似乎更加灵活，而 MSBuild 可以构建 VS 解决方案这一事实是它的一大优势。我发现创建构建脚本的最简单方法是同时使用 NAnt 来调用构建的不同部分(构建、fxcop、测试、覆盖率等)和 MSBuild 来执行实际构建。

关于 MSTest，我没什么好说的。例如在构建服务器上安装既缓慢又麻烦。它不是很灵活，并且具有各种“附加功能”，似乎更适合集成测试而不是单元测试。我发现轻量级 XUnit.Net、MBUnit 或 NUnit 更适合单元测试。速度在这里很重要，您希望经常运行测试，以便快速反馈代码更改的效果。便携性也很重要。您希望让测试在任何地方运行，而无需进行大量设置和黑客攻击，就像在未安装团队系统的计算机上需要 MSTest 一样。尽管单元测试并不新鲜，但仍有大量开发正在进行。最佳实践发生了很大变化，工具也发生了很大变化。我不想受制于 Visual Studio 每隔几年才升级一次的工具。三个 OSS .net 单元测试工具中的每一个都被设置为可扩展的。 MSTest 不是(据我所知)。