断言等式,什么是实际的,什么是预期的?

2022-09-01 14:26:20

我一直想知道在像TestNG这样的库中,实际和预期的含义究竟是什么。assertEquals

如果我们阅读Java文档,我们会看到:

public static void assertEquals(... actual, ... expected)
Parameters:
    actual - the actual value
    expected - the expected value

根据我的理解,这个值是已知的,所以我们期望的那个,而这个值就是我们想要验证的那个。例如,假设我们要测试一个始终必须返回 .expectedactualfooBar56

在这种情况下,我会这样做:.但是,通过在GitHub上进行快速搜索,似乎人们会以相反的方式进行搜索,因此.但是,当我们甚至不知道预期值时,它怎么可能呢?这似乎是我们将与我们已经知道的预期进行比较的实际值。assertEquals(sth.fooBar(), 56)assertEquals(56, sth.fooBar())sth.fooBar()sth.fooBar()

我知道测试的正确性没有区别,但我想遵循“正确”的方式。


答案 1

大多数测试框架(xUnit系列)都基于JUnit框架。JUnit中的函数系列具有以下格式;它成为一项公约,大多数其他框架都遵循该公约。Assert(expected, actual)

一些框架(如TestNG或NUnit 2.4+的.NET)颠倒了这种顺序(通过使用基于约束的NUnit模型)来提高可读性(“确保实际值为56”感觉比“确保56是实际值”更自然)。

底线是:坚持框架的惯例。如果使用 JUnit,请先输入预期值。如果使用 TestNG,请先输入实际值。你是对的,当你不小心反转参数时,测试结果没有区别。但是,它与您从失败的测试中获得的默认消息有很大的不同。当您在 JUnit 中反转失败时,默认消息显示“预期 [false]但发现 [true]”,其中应显示“预期 [true] 但发现 [false]”。至少可以说,这是令人困惑的,您不必处理该消息的可能误导。assertEquals(ShouldBeTrueButReturnsFalse(), true)

您提供的 Github 链接中的某些单元测试不遵循约定,并且存在相同的问题。别这样。坚持框架的惯例


答案 2

答案很简单。JUnit 具有相反的参数顺序。请参考以下示例:

JUnit:

void assertEquals(Object expected, Object actual)

TestNG:

void assertEquals(int actual, int expected)


推荐