在.NET v1期间,我尝试使用NUnit和NAnt的其他工具来说服同事开发测试驱动和自动构建的工作习惯,但没有取得太大成功.当.NET Framework 2.0和Visual Studio 2005 Team Suite出现时,我能够"强迫"我的团队编写测试并在Visual Studio中为自己提供可视化测试.我还能够通过额外的MSBuild任务来调整项目文件,以实现更多的构建自动化.
当然,这并不意味着微软已经提供了完美的系统,但我相信他们已经采取了正确的步骤.所有这些功能都融入到框架和产品中并成为"原生",它使得动作开发人员更容易进入更好的开发实践.
很久以前就忘记了开源选项(我确实错过了),我想知道当前NUnit和NAnt的化身是什么价值主张？在这个阶段,人们可以争论说服团队不使用MSBuild或MSTest？
澄清:我的公司是一个纯粹的微软SI.Visual Studio Team Suite版本,Database Professional版本,TFS等可供我们使用.我们不使用Visual Studio Professional版本或更小版本.
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不是(就我所见).
京公网安备 11010802040832号 | 京ICP备19059560号-6 