我有一种情况(下面详细介绍),我想在所有其他测试完成后再运行一个NUnit测试。我知道我可以使用order属性以一定顺序 start 进行测试,但在这种情况下:
我已经尝试过OneTimeTearDown,但理想情况下,它将作为常规的命名测试运行,并以这种方式出现在测试结果中。
(为什么)
我有数百个命名的手工测试,它们针对json测试文件的不同文件夹运行。非程序员有时会向这些文件夹添加文件。最终测试的目的是对这些文件夹进行内部检查,并将磁盘上的内容与已经执行了测试的文件进行比较(每个测试都记录了这些文件)。如果这表明存在未经测试的文件,则该文件本身构成测试失败。
答案 0 :(得分:0)
这是一个有趣的问题。基本上,您需要一种元测试...一种测试您的测试水平的测试。因此,实际上成为测试是合乎逻辑的。
不幸的是,NUnit在OneTimeTearDown中仅支持这种“万事俱备”。现在,您可以在OneTimeTearDown中执行断言,但是将任何失败都视为错误,即意外异常。出于某些目的,这可能是可行的,但看起来与失败并不完全相同。
如果我这样做的话,我认为在运行测试之后,我会在脚本中将其作为一个单独的分析步骤。