单元测试:为什么在等式测试中预期参数总是首先出现? [英] Unit testing: why is the expected argument always first in equality tests?

问题描述

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

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

等

我现在已经很习惯了，但是我尝试教单元测试的每个编码员都会犯颠倒参数的错误，我完全理解这一点.谷歌没有帮助，也许这里的核心单元测试人员之一知道答案?

解决方案

似乎大多数早期框架在实际之前使用了预期(但由于某些未知原因，掷骰子也许?).然而，随着编程语言的发展和代码流畅性的增加，这个顺序被颠倒了.大多数流畅的界面通常试图模仿自然语言，单元测试框架也不例外.

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

<块引用>

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

代替

<块引用>

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

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

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

听起来不错.现在:

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

嗯..?如果有人告诉您玫瑰是红色的，您可能不会太惊讶.反过来说，红色是玫瑰，提出了可疑的问题..

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

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

你会如何扭转那个?森林中有超过 15 棵树?

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

Why is it that every unit testing framework (that I know of) requires the expected value in equality tests to always be the first argument:

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

assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything());

etc.

I'm quite used to it now, but every coder I try to teach unit testing makes the mistake of reversing the arguments, which I understand perfectly. Google didn't help, maybe one of the hard-core unit-testers here knows the answer?

解决方案

It seems that most early frameworks used expected before actual (for some unknown reason though, dice roll perhaps?). Yet with programming languages development, and increased fluency of the code, that order got reversed. Most fluent interfaces usually try to mimic natural language and unit testing frameworks are no different.

In the assertion, we want to assure that some object matches some conditions. This is the natural language form, as if you were to explain your test code you'd probably say

"In this test, I make sure that computed value is equal to 5"

instead of

"In this test, I make sure that 5 is equal to computed value".

Difference may not be huge, but let's push it further. Consider this:

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

Sounds about right. Now:

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

Hm..? You probably wouldn't be too surprised if somebody told you that roses are red. Other way around, red are roses, raises suspicious questions. Yoda, anybody?

Yoda's making an important point - reversed order forces you to think.

It gets even more unnatural when your assertions are more complex:

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

How would you reverse that one? More than 15 trees are being had by forest?

This claim (fluency as a driving factor for modification) is somehow reflected in the change that NUnit has gone through - originally (Assert.AreEqual) it used expected before actual (old style). Fluent extensions (or to use NUnit's terminology, constraint based - Assert.That) reversed that order.

这篇关于单元测试:为什么在等式测试中预期参数总是首先出现?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！