如何使用 MSTest/CCNet 警告因外部影响而导致的测试失败
我们的在线服务中有一部分与第三方网络服务集成。因此,我们在 Visual Studio 2010 中使用 MSTest 进行了大量单元测试,以确保我们与第三方的事务产生预期的响应。我们运行 CCNet 来进行持续构建,并且能够准确地完成持续集成的目的,这真是太棒了。在许多情况下,它发现上游层中的签入更改了我们服务端的数据并破坏了集成。
不幸的是,第三方的集成测试主机并不可靠,因为它可能会在没有警告的情况下停机进行维护。因此,每天都会有几次由于这些单元测试因连接问题而失败而导致构建被破坏。这是非常分散注意力的,除了将其标记为可接受的结果路径之外,我们对此无能为力。因此,我们的许多测试如下所示:
var client = new ThirdPartyClient(TestConfig);
var Result = client.DoSomethingOverThere(ourDataToSend);
Assert.IsFalse(Result == BadResult)
Assert.IsTrue((Result == Success) || (Result == Timeout))
我真的很想知道这两个可能结果中的哪一个导致测试通过。 (实际上,我希望有一种方法可以使用 Assert.Inconclusive,而不将其视为损坏的构建)但是有人对如何处理这种情况有任何建议吗?
We have a section of our online service that integrates with a third party webservice. So we have a large number of unit tests using MSTest in Visual Studio 2010 that make sure that our transactions with the third party result in the expected responses. We run CCNet for continuous builds and it has been great doing exactly what continuous integration is meant to do. On many occaisions it found out when checkins in upstream layers altered the data on our end of the service and broke the integration.
Unfortunately the third party's integration test host is unreliable in that it can be down for maintenance without warning. So there are several times a day when the build will become broken due to these Unit Tests failing with connection problems. This is very distracting and there is nothing we can do about it except mark this as an acceptable result path. A lot of our test therfore look like the following:
var client = new ThirdPartyClient(TestConfig);
var Result = client.DoSomethingOverThere(ourDataToSend);
Assert.IsFalse(Result == BadResult)
Assert.IsTrue((Result == Success) || (Result == Timeout))
I'd really like to know which of the two possible results caused the test to pass. (In reality I wish that there was a way to use Assert.Inconclusive without it counting as a broken build) But does anyone have any recommendations on how to handle this situation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
This post addressing Inconclusive Tests in TFS Build Should Not Break the Build is explaining a workaround that might be applicable for your situation. I agree that setting the Inconclusive state to the test when your other party has problems is a pragmatic way of dealing with this issue.