assertEquals,什么是实际的和预期的？

Question

我总是想知道assertEquals像TestNG这样的库中实际和预期的含义究竟是什么.

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

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

从我的理解,expected价值是已知的,所以我们期望的那个,actual一个是我们想要验证的.例如,假设我们要测试fooBar一直必须返回的函数56.

在这种情况下,我会这样做:assertEquals(sth.fooBar(), 56).但是通过快速搜索GitHub,似乎人们可以反过来这样做,所以assertEquals(56, sth.fooBar()).但是,sth.fooBar()当我们甚至不知道这个价值时,预期价值怎么样呢？这似乎sth.fooBar()是我们与我们已经知道的预期值进行比较的实际值.

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

Answer 1

大多数测试框架(xUnit系列)都基于JUnit框架.将Assert在JUnit的系列函数有(expected, actual)格式; 它成为一种惯例,大多数其他框架都遵循该惯例.

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

底线是:坚持框架的惯例.如果使用JUnit,请将期望值放在第一位.如果您使用TestNG,请先将实际值放入.你是对的,当你意外地反转参数时,测试结果没有任何区别.但它会对您从失败的测试中获得的默认消息产生重大影响.当您在JUnit中的反转 assertEquals(ShouldBeTrueButReturnsFalse(), true)失败时,默认消息显示" expected [false]但找到[true] ",其中应该说" expected [true]但找到[false] ".至少可以说这是令人困惑的,你不应该处理可能误导的消息.

您提供的Github链接中的某些单元测试不符合约定并且具有相同的问题.不要那样做.坚持你的框架的惯例.

Answer 2

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

JUnit的:

void assertEquals(Object expected, Object actual)

TestNG的:

void assertEquals(int actual, int expected)