单元测试:为什么预期的参数总是在相等测试中首先出现？

Question

为什么每个单元测试框架(我知道:)要求相等测试中的期望值始终是第一个参数:

Assert.AreEqual(42, Util.GetAnswerToLifeTheUniverseAndEverything());

assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything());

等等

我现在已经习惯了,但是我尝试教单元测试的每个编码器都会错误地反转参数,我完全理解.谷歌没有帮助,也许这里的核心单位测试人员之一知道答案？

Answer 1

看起来大多数早期的框架在实际使用之前都是预期的(虽然有些未知的原因,骰子可能会滚动？).然而,随着编程语言的发展和代码流畅度的提高,这种顺序得到了逆转.大多数流畅的界面通常试图模仿自然语言,单元测试框架也不例外.

在断言中,我们希望确保某些对象符合某些条件.这是自然语言形式,就像您要解释您可能会说的测试代码一样

"在这个测试中,我确保计算值等于5"

代替

"在这个测试中,我确保5等于计算值".

差异可能不是很大,但让我们进一步推动它.考虑一下:

Assert.That(Roses, Are(Red));

听起来很对.现在:

Assert.That(Red, Are(Roses));

嗯..？如果有人告诉你玫瑰是红色的,你可能不会太惊讶.换句话说,红色是玫瑰,引发了可疑的问题.尤达,有人吗？

尤达的重要观点 - 颠倒的秩序迫使你思考.

当你的断言更复杂时,它会变得更加不自然:

Assert.That(Forest, Has.MoreThan(15, Trees));

你会如何逆转那一个？森林里有超过15棵树？

这种说法(流畅性作为修改的驱动因素)在某种程度上反映在NUnit经历的变化中 - 最初(Assert.AreEqual)它在实际(旧式)之前使用了预期.流畅的扩展(或使用NUnit的术语,基于约束 - )颠倒了该顺序.Assert.That

Answer 2

我认为这只是一个惯例,正如你所说的那样,它被"每个单元测试框架(我知道)"所采用.如果您正在使用框架,那么切换到使用相反约定的另一个框架会很烦人.所以(例如,如果您正在编写新的单元测试框架),您最好遵循现有的约定.我相信这来自一些开发人员喜欢编写相等测试的方式:

if (4 == myVar)

为了避免任何不需要的分配,错误地写一个"="而不是"==".在这种情况下,编译器将捕获此错误,您将避免尝试修复奇怪的运行时错误的许多麻烦.

Answer 3

我不知道,但我参与了几个关于平等测试论证顺序的动画讨论.

有很多人在想

if (42 == answer) {
  doSomething();
}

比较好

if (answer == 42) {
  doSomething();
}

在基于C语言.原因是如果你不小心把一个等号:

if (42 = answer) {
  doSomething();
}

会给你一个编译错误,但是

if (answer = 42) {
  doSomething();
}

可能不会,并且肯定会引入一个可能难以追踪的错误.所以谁知道,也许建立单元测试框架的人/人习惯于以这种方式思考相等测试 - 或者他们正在复制已经以这种方式设置的其他单元测试框架.

Answer 4

没人知道,这是永无止境的混乱的根源.然而,并非所有框架都遵循这种模式(更令人困惑):

1. FEST-Assert使用正常顺序:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything()).isEqualTo(42);
   

2. Hamcrest:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything(), equalTo(42))
   

3. ScalaTest并没有真正区分:

   Util.GetAnswerToLifeTheUniverseAndEverything() should equal (42)