如何让UnitTest在一段时间后自动失败?

发布于 2024-07-10 19:40:24 字数 448 浏览 8 评论 0原文

我正在使用 NUnit (2.4.6),我的构建/测试之夜是使用 Team City 4 完成的。我已经联系了 Team City,他们已经告诉我他们无法处理这个问题。 所以,我来了。

我想要的是设置我的测试以像往常一样进行测试,但如果他们挂起......出于未知原因(这可能会发生......)......我不希望他们继续但失败。 这是必需的,因为有时我注意到我的构建之夜已经完成,而当测试到达时,一些测试会挂起整个晚上。

你会怎么做?

请记住,我知道 Nunit 2.5(Beta)具有 MaxTime 属性 但我必须升级 + 进行超过 800 个单元测试...我想要一些用于整个测试的东西,而不必升级到这个测试版本。

I am using NUnit (2.4.6) and my build/test night are done with Team City 4. I have contacted team city and they already told me that they cannot handle this. So, here I am.

What I want is to set up my test to do their testing as usual but in the case they hang up... for an unknown reason (this might happen...)... I do not want them to continue but to fail. This is require because sometime I have notice my build night was done and when testing arrive some test hang up for the whole night.

How would you do it?

Have in mind that I know that Nunit 2.5 (Beta) have the MaxTime attribute but I would have to upgrade + do it over 800 units tests... I would like something for the whole tests without having to upgrade to this beta version yet.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

两相知 2024-07-17 19:40:24

TC 对每个构建配置都有一个执行超时,如果超过则构建失败。
在一般设置中,“如果运行时间超过则构建失败”。
它不是每个单元测试,但我认为它对于您的场景来说已经足够好了。

TC has an execution timeout for each build configuration, which fails the build if exceeded.
It's in general settings "fail build if it runs longer than".
It's not per unit test, but I think it's good enough for your scenario.

孤者何惧 2024-07-17 19:40:24

如果您坚决反对升级到 2.5,NUnit 示例中有一个 MaxTimeDecorator,如果花费的时间超过指定的时间,它将导致测试失败。 显然,当测试挂起时,这不会有帮助,但您可能可以修改示例,以便它在自己的线程中生成测试,并每隔一段时间进行回调以查看是否超出了时间限制。 然而,这很快就会变得相当复杂。

If you're dead set against upgrading to 2.5 there is a MaxTimeDecorator in the NUnit samples which will fail the test if takes longer than the specified time. Obviously this won't help when the test hangs, but you can probably modify the sample so it spawns off the test in its own thread and has a call back every so often to see if the time limit has been exceeded. This however would get rather complicated very quickly.

听你说爱我 2024-07-17 19:40:24

我会按照您的建议使用 MaxTime,这是执行此操作的标准方法 - 为什么要费心创建新的东西以避免更新测试本身?

如果问题只是更新测试所花费的时间,我个人可能会敲出一些快速而肮脏的程序来解析源文件并添加属性。
可能有更好的方法来更新代码(生成器或其他),但这会起作用。

除非有令人信服的理由不使用 NUnit 2.5?

I'd use the MaxTime as you suggest, that's the standard way of doing it - why bother to create something new just to avoid updating the tests themselves?

If the problem is simply the amount of time taken to update the tests, personally I'd probably knock up some quick and dirty program to parse the source files and add the attribute.
There are probably better way of updating the code (generators or whatever), but that would work.

Unless there's a compelling reason not to use NUnit 2.5?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文