Question

当使用Asert(......)时,如果符合逻辑的测试失败,单位测试的其余部分就算起。是否有办法使合乎逻辑的检验失败,但只是发出警告或提供某种东西,并且仍然进行其他单位测试?

这方面的一个例子是,我进行了一项测试,培养了一些学生、教师和班级,建立关系,然后将他们纳入一个数据库。然后,一些SSIS的包件在数据库上运行,该数据库将现有数据转换成另一个数据库图谱。然后,测试需要对新数据库进行核对,以了解浏览量、行动等正确数量。

显然,其他测试是删除和改动的,但所有测试都遵循同样的结构——在源db中生成数据,操作SSIS包,核实目标db中的数据。

Answer 1

就像你试图在一次测试中测试太多东西一样。

如果一个先决条件没有得到满足,那么假定测试的其余部分也不会通过。我更愿意在我知道事情是我所期望的时,即结束试验。

单位测试的概念是“红色失败”,绿色通行证。我知道,“管理系统试验”也允许一个黄色,但现在还没有做你想要做的事情。你们可以做阿森特。无法取得黄色光。我在努力建立依靠具体数据库数据的许多一体化测试的代码基时就使用了这一方法。我开始的不是测试失败,而是结果没有结果。该法典可能只做了罚款,但数据缺失。没有理由认为数据永远存在(这些并非海事组织的良好测试)。

Answer 2

如果你使用,Gallio/MbUnit<>,你可使用 rel=“nofollow”>,<<。它抓住了失败的说法,但没有立即停止立即执行试验。所有未完成的说法都在测试结束后收集和报告。

[Test] public void MultipleAssertSample() { Assert.Multiple(() => { Assert.Fail("Boum!"); Assert.Fail("Paf!"); Assert.Fail("Crash!"); }); }

The test in the example above is obviously failing but what s insteresting is that the 3 failures are shown in the test report. The execution does not stop at the first failure.

Answer 3

几年前我曾问过你的问题。但最近(大约2017年或2018年)NUNIT 3支持警告。你们可以在Asert中进行[细菌]试验。警告大家。 Fail。但是,测试过程不是整个测试失败的单一Asert线,而是将显示警报,并在试验中继续进行。

阅读:rel=“nofollow noreferer” https://docs.nunit.org/articles/nunit/even-tests/Warnings.html

It behaves similarly to Multiple (listed by @Yann Trevin above, and Multiple is also available in NUnit 3.0). The cool difference though is on integration tests where having the flexibility of using stand-alone Assert.Warning commands shines. Contrast to a group Asserts within a Multiple instance. Once the Multiple assert has completed, the test may not continue.

一体化测试,尤其是那些能够运行数小时的一体化测试,或许可以测试一夫一妻的微型服务如何发挥作用,因此,重新运行成本很高。而且,如果你会有多个团队(外部、内部、外部、内fer和间歇)和时间区,几乎全时都投入使用,那么,一旦所有东西都放在一起,就很难获得新的产品,以开始对终端进行一体化测试。 (注 - 重要的是,必须汇集具备充分领域知识的团队,并至少配备足够的软件工程知识,以汇集可靠的“合同”,使每一份软件都能够使用和管理。这样做应有助于缓解上述错误。

简便的黑色/白色、通行证/航道测试对单位测试绝对正确。

但是,随着系统更加抽象,在服务后、代理人之后,能够了解系统健全性和可靠性,变得更加重要。我们已经知道,法典的小部分将按预期发挥作用;联检组的测试和法典覆盖面告诉我们。但是,当他们必须经营其他基础设施(AWS、谷歌云)时, 单位检测不足。

了解有多少次服务需要重新入场,服务费用多少,鉴于某些负荷,该系统能否满足苏丹解放军的要求? 这些是融合测试能够帮助利用你要求的Asert, @dnatoli。

鉴于你提出问题以来的几年,你现在几乎肯定会再次担任专家。

Answer 4

从你在问题中所解释的角度来看,接受测试(比单位测试)越多。单位测试框架设计得很快失败。这就是为什么Assert的行为方式(及其好事)

Coming back to your problem: You should take a look at using an acceptance testing framework like Fitnesse, which would support what you want i.e. show me the steps that failed but continue execution till the end.
However if you MUST use a unit-testing framework, use a collecting variable/parameter to simulate this behavior. e.g.

Maintain a List<string> within the test
append a descriptive error message for every failed step
At the end of the test, assert that the collecting variable is empty

Answer 5

我在想获得一份比喻更有意义的失败报告时,也存在同样的问题。我对收集资料进行了比较,并用来得出错误的内容数目——没有任何想法是失败的真正原因。不幸的是,我最后以人工方式撰写一份比较文件,以便检查所有条件,然后在最后用一个错误信息作单一表述。

Answer 6

单位测试是黑白的,要么通过测试,要么没有,要么是破碎逻辑的,要么是正确的,要么是不正确的(尽管与非行的单位测试本身已不再是单位测试)。

你们将做些什么? 这是否通过? 如果它通过,那么在这种情况下单位测试点是什么? 如果失败,那就失败了。

我建议花费一些时间,以划分应测试的单位,以及如何对单位进行测试。 “大学测试”是一种陈词滥调,许多人用于非常不同的事物。

Answer 7

单位检测可能比融合测试这样的东西更黑白,但如果你使用像间歇流动这样的工具,那么你可能需要测试框架,以向你们发出警告或坚持无结果。

为什么有些单位测试框架允许你在黑人和白人中坚持无结果吗?

判断你重新通过单位测试的测试日期是随机数据生成者...... 或许你们有其中几项,......因为某些数据条件,你确信,另一天没有给你附加条件可能无法保证......

警告或某种不确定因素的意思是告诉工程师看看一看这个独角兽案件,并增加更多的代码,以争取在以后赶上。

假设你的测试永远是完美的或黑白的,我不认为它正确无误,我会陷入太多的病例和15年的测试,而它不会通过或失败......它会穿过......我不知道......。你想到的是,当你没有测试,就意味着你知道它失败了。

在自动测试中,合法故障确实是坏的。它带来了许多噪音......你更不用说我不知道你是否知道你正在失败......

友情链接