在 nunit 测试中,我们是否可以断言如果测试在某种情况下失败,那么它就是通过(即预期会尝试并失败)。
但它应该在所有其他情况下通过。
问题是测试可能会在它到达它的断言部分之前分崩离析。
我的意思是
[TestSetup]
void init()
{
if (condition==true)
{
Assert.That(this test fails); /*any feature to do this?*/
}
}
在 nunit 测试中,我们是否可以断言如果测试在某种情况下失败,那么它就是通过(即预期会尝试并失败)。
但它应该在所有其他情况下通过。
问题是测试可能会在它到达它的断言部分之前分崩离析。
我的意思是
[TestSetup]
void init()
{
if (condition==true)
{
Assert.That(this test fails); /*any feature to do this?*/
}
}
如果测试可能失败并且在某些情况下被归类为通过,那么这听起来是一个糟糕的测试。将其拆分为单独的测试,并使用清晰的方法名称详细说明其实现的目标。
因此,与其进行一个测试并在其中包含一个条件,不如将其拆分为每个场景。这样你就可以有一个场景,它应该在类似的情况下失败
// do stuff
bool success = DoStuff();
Assert.IsFalse(success);
有点难以理解你的问题。你想Assert.Fail()
强迫失败吗?像这样...
[TestSetup]
public void Init()
{
if (condition==true)
{
Assert.Fail();
}
}
相反,如果您想检查失败而不是原因失败,则应遵循 Arran 的建议并检查有关您正在验证的工作的特定事实 - 例如方法的返回值。
您还可以使用“动作”对象来调用动作中的代码并测试该动作是否是异常。看看 FluentAssertions 他们有很多例子。
int number1 = 1;
int number0 = 0;
Action someAction = () => { int j = number1 / number0; };
someAction.ShouldThrow<DivideByZeroException>();