整个团队中是否有人真正成功地使用了 MSTest？
到目前为止，我一直在使用 MSTest 进行单元测试，发现它有时会无缘无故地随机破坏我的构建。构建在 VS 中会失败，但在 MSBuild 中可以正常编译 - 出现类似“选项严格不允许 IFoo 转换为 IFoo 类型”的错误。我相信我终于修复了它，但是在 bug 回来并努力让它再次消失之后，并且 MS 的帮助很少，它给我留下了不好的印象。 正在寻找其他选项。
我还注意到，在查看这个论坛和其他博客等时，大多数人都在使用 NUnit、xUnit 或 MBUnit。顺便说一句，我们使用的是 VS2008。所以现在我 致力于让我们的团队开始进行 TDD 和实际单元测试，并计划一些培训，但首先想拿出一套标准工具和工具。最佳实践。为此，我一直在网上寻找适合构建服务器和开发机器的基础设施...我正在查看 typemock 网站，因为我听说过有关他们的模拟框架的精彩内容，并注意到他们似乎在推广 MSTest，甚至有一些人们移动的链接 TO MSTest from NUnit..
这让我重新考虑我的决定.. 所以我想我在问 - 有没有人使用MSTest 作为 TDD 基础设施的一部分？如果我想与构建/CI 服务器、代码覆盖率或我可能需要的任何其他类型的 TDD 工具集成，它有任何已知的限制吗？我确实搜索了这些论坛，大多数发现人们将第 3 方框架相互比较，甚至没有给 MSTest 太多机会......有充分的理由吗......？
感谢您的建议
编辑：感谢此线程中的回复，我已经确认 MSTest 适合我的目的，并与 CI 工具和构建服务器优雅地集成。
但有人有 FinalBuilder 的经验吗？我希望我们将这个工具用于构建脚本，以防止与其他构建工具相比编写大量 XML。在进行 MS Test 之前我应该注意哪些限制？
我还应该注意 - 我们正在使用 VSS =(。我希望我们能够尽快取消它 - 希望作为建立所有这些基础设施的一部分，甚至可能是第一步。
I've been using MSTest so far for my unit-tests, and found that it would sometimes randomly break my builds for no reason. The builds would fail in VS but compile fine in MSBuild - with error like 'option strict does not allow IFoo to cast to type IFoo'. I believe I have finally fixed it, but after the bug coming back and struggling to make it go away again, and little help from MS, it left a bad taste in my mouth. I also noticed when looking at this forum and other blogs and such, that most people are using NUnit, xUnit, or MBUnit.. We are on VS2008 at work BTW.. So now I am looking to explore other options..
I'm working on moving our team to start doing TDD and real unit testing and have some training planned, but first would like to come up with a set of standard tools & best practices. To this end I've been looking online to come up with the right infrastructure for both a build server and dev machines...I was looking at the typemock website as I've heard great things about their mocking framework, and noticed that it seems like they promote MSTest, and even have some links of people moving TO MSTest from NUnit..
This is making me re-think my decision.. so I guess I'm asking - is anyone using MSTest as part of their TDD infrastructure? Any known limitiations it has, if I want to integrate with a build / CI server, or code coverage or any other kind of TDD tool I may need? I did search these forums and mostly find people comparing the 3rd party frameworks to eachother and not even giving MSTest much of a chance... Is there a good reason why.. ?
Thanks for the advice
EDIT: Thanks to the replies in this thread, I've confirmed MSTest works for my purposes and integreated gracefully with CI tools and build servers.
But does anyone have any experience with FinalBuilder?? This is the tool that I'd like us to use for the build scripts to prevent having to write a ton of XML compared to other build tools. Any limitiations here that I should be aware of before committing to MS Test?
I should also note - we are using VSS =(. I'm hoping we can ax this soon - hopefully as part of, maybe even the first step, of setting up all of this infrastructure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 Safewhere，我们目前使用 MSTest 进行 TDD，效果还不错。
就我个人而言，我喜欢 IDE 集成，但不喜欢 API。如果可以将 xUnit.NET 与 VS 测试运行程序集成，我们将很快进行迁移。
至少对于 TFS，MSTest 作为我们 CI 的一部分工作得很好。
总而言之，我发现 MSTest 对我来说足够有效，但我并不坚持使用它。
如果您正在评估模拟库，请查看 这个比较。
At Safewhere we currently use MSTest for TDD, and it works out okay.
Personally, I love the IDE integration, but dislike the API. If it ever becomes possible to integrate xUnit.NET with the VS test runner, we will migrate very soon thereafter.
At least with TFS, MSTest works pretty well as part of our CI.
All in all I find that MSTest works adequately for me, but I don't cling to it.
If you are evaluating mock libraries, take a look at this comparison.
自从 VS 2008 发布以来，我一直在使用 MS Test，但我在工作中还没有成功地使用 TDD 或 CI 之类的东西，尽管我在尝试构建 CI 服务器时稍微搞乱了 Cruise Control在我本地的盒子上。
总的来说，我发现 MS Test 对于本地测试来说相当不错，但对于机构使用来说存在一些痛点。
首先，MS Test 添加了很多可能不属于源代码管理的内容。 .VSMDI 文件特别烦人；只需运行 MS Test 即可创建其中 1 到 5 个并将它们添加到解决方案文件中。这意味着源代码管理中的 .SLN 会发生变化，而这种变化是很糟糕的。
我理解这些额外文件背后的假设点——跟踪测试运行历史记录等——但我发现它们对除了单个开发人员之外的任何人都没有特别有用。您应该使用构建服务和 CI 来完成此类事情！
其次，您必须拥有 Team Foundation Server 来运行单元测试作为 CI 的一部分，或者如果您使用 Cruise Control，则必须在构建服务器上安装 Visual Studio 的副本。网。有关详细信息，请参阅此 Stack Overflow 问题。
总体来说MS Test没有什么问题。但走向 CI 并不会像想象中那么顺利。
I've been using MS Test since VS 2008 came out, but I haven't managed to strong-arm anything like TDD or CI here at work, although I've messed with Cruise Control a little in an attempt to build a CI server on my local box.
In general I've found MS Test to be pretty decent for testing locally, but there are some pain points for institutional use.
First, MS Test adds quite a few things that probably don't belong in source control. The .VSMDI files are particularly annoying; just running MS Test creates anywhere from 1 to 5 of them and adds them to the solution file. Which means churn on your .SLN in source control, and churn of that sort is bad.
I understand the supposed point behind these extra files -- tracking test run history and such -- but I don't find them particularly useful for anything but a single developer. You should use your build service and CI for that sort of thing!
Second, you either must have Team Foundation Server to run your unit tests as part of CI, or you have to have a copy of Visual Studio installed on your build server if you use, for example, Cruise Control.NET. See this Stack Overflow question for details.
In general, there's nothing wrong with MS Test. But going CI will not be as smooth as it could be.
我在我们公司使用 MSTest 非常成功。我们目前正在公司内部建立标准化构建流程，到目前为止，我们在 TeamCity 方面取得了良好的成功。对于持续集成，我们使用开箱即用的 TeamCity 配置。对于实际的发布版本，我们设置了大型 msbuild 脚本来自动化整个过程。
我真的很喜欢 mstest，因为它集成了 IDE，而且我们所有的开发人员都可以自动使用它，而无需安装任何第三方依赖项。我不建议仅仅因为您遇到的问题而进行切换。我又绕了一圈，我们去了nunit，然后又回来了。这些框架最终都是相同的，因此请选择最适合大多数开发人员访问并开始使用的框架。
我怀疑你的问题可能是......听起来像是我以前遇到过的一个晦涩的问题，其中错误的 dll 引用（例如：向解决方案中的项目添加显式引用（通过浏览），而不是使用项目引用）会导致问题仅在干净的签出或构建后才会出现的最新问题。
我之前发现的另一个真正可疑的问题是，如果您有一些可视组件或控件，它们具有在表单 .resx 文件中序列化的某种自定义类型的公共属性。我通常需要使用 SerializationVisibility.Hidden 属性来标记它们。这意味着 IDE 不会尝试为属性值（通常是某个对象图）生成 setter。只是一个想法。可能还有出路。
我信任这些工具，而且它们并没有谎称存在真正的问题。他们只是歪曲事实或将其报告为完全晦涩难懂的东西。我觉得你好像有这个。我怀疑这一点是因为如果一切正常，错误消息没有意义，但如果此时某些代码加载了过时或修改版本的 dll，则错误消息确实有意义。
I have been using MSTest very successfully in our company. We are currently setting up standardised build processes within our company and so far, we have had good success with TeamCity. For Continuous integration, we use out the box TeamCity configurations. For the actual release builds, we set up large msbuild scripts that automate the entire process.
I really like mstest because of the IDE integration and also that all our devs automatically can use it without installing any 3rd party dependencies. I would not recommend switching just because of the problem you are experiencing. I have come full circle, where we went over to nunit and then came back again. These frameworks are all the same at the end of the day so pick the one that is easiest for most your devs to get access to and start using.
What I suspect your problem might be... sounds like an obscure problem I have had before where incorrect references of dll's (eg: adding explicit references (via browse) to projects in your solution, and not using the project reference) leads to out-of-date problems that only come up after clean checkouts or builds.
The other really suspect issue that I have found before is if you have some visual component or control that has a public property of some custom type that is being serialised in the forms .resx file. I typically need to flag them with an attribute that says SerializationVisibility.Hidden. This means that the IDE will not try to generate setters for the property value (which is typically some object graph). Just a thought. Could be way out.
I trust the tools and they don't really lie about there being a genuine problem. They only misrepresent them or report them as something completely obscure. It sounds to me like you have this. I suspect this because the error message doesn't make sense if all is in order, but it does make sense if some piece of code has loaded up an out of date or modified version of the dll at that point.
我已经成功部署了多个 FinalBuilder 安装，客户对结果非常满意。我强烈推荐它。
I have successfully deployed several FinalBuilder installations and the customers have been very happy with the outcome. I can highly recommend it.