为什么assertEquals（）参数的顺序为（预期的，实际的）？

Question 1

为什么这么多assertEquals()或类似的函数将期望值作为第一个参数，而将实际值作为第二个参数？
这对我来说似乎是违反直觉的，那么这个异常的命令是否有特定的原因？

Question 2

因为作者有50％的机会符合您的直觉。

由于其他过载

assertWhatever(explanation, expected, actual)

并且，作为您所知道的部分的解释与所期望的（即您所知道的，而不是实际的）相吻合，而不是您在编写代码时不知道的实际情况。

Question 3

在回答来自肯特·贝克，苏尼特和JUnit（其中可能这个约定起源）的创造者，是：

在一行中插入一串assertEquals。首先有期望，使他们阅读更好。

但是，这与我自己的经历正好相反，以至于我不得不怀疑自己是否误解了。这是我在测试中经常看到的内容：

assertEquals(12345, user.getId());
assertEquals("kent", user.getUsername());
assertEquals("Kent Beck", user.getName());

我认为首先使用实际值会更好。这将更多的重复样板放在一起，使我们正在测试其值的方法调用对齐：

assertEquals(user.getId(), 12345);
assertEquals(user.getUsername(), "kent");
assertEquals(user.getName(), "Kent Beck");

（还有其他一些原因使我更喜欢这种顺序，但是出于这个关于为什么是另一种方式的问题，即使我不理解，肯特的推理也似乎是答案。）

Question 4

我同意一致性是第一位的共识，但是如果您正在评估这个问题，比较字典的行为可能是一个有用的数据点。

当我在差异上看到“ +”时，我将其读为“正在测试的过程添加了它”。同样，个人喜好适用。

注意：我使用字母键并增加了字典的长度，因此为了示例的清楚，仅中间键会发生变化。其他方案显示更多混淆的差异。同样值得注意的是，assertEqual在> = 2.7和> = 3.1中使用assertDictEqual

例题

from unittest import TestCase


class DictionaryTest(TestCase):

    def test_assert_order(self):
        self.assertEqual(
            {
                'a_first_key': 'value',
                'key_number_2': 'value',
                'z_last_key': 'value',
                'first_not_second': 'value',
            },
            {
                'a_first_key': 'value',
                'key_number_2': 'value',
                'z_last_key': 'value',
                'second_not_first': 'value',
            }
        )

输出：

$ python -m unittest exl
F
======================================================================
FAIL: test_assert_order (exl.DictionaryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "exl.py", line 18, in test_assert_order
    'second_not_first': 'value',
AssertionError: {'a_first_key': 'value', 'z_last_key': 'value', 'key_number_2': 'value', 'first_ [truncated]... != {'a_first_key': 'value', 'z_last_key': 'value', 'key_number_2': 'value', 'second [truncated]...
  {'a_first_key': 'value',
-  'first_not_second': 'value',
   'key_number_2': 'value',
+  'second_not_first': 'value',
   'z_last_key': 'value'}

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

Question 5

这是一个很有启发性的话题，这里也有很多非常有教育意义的答案！这是我从他们那里学到的东西：

直觉/反直觉可以被认为是主观的，因此，无论最初定义的顺序是什么，也许我们中的50％都不高兴。
我个人更希望将其设计为assertEqual(actual, expected)，因为鉴于assert和之间的概念相似性if，我希望它遵循的规范if actual == expect，例如if a == 1。

（PS：的确，有不同的意见会提示您以“相反的顺序”编写if语句if(1==a) {...}，例如，以防止您意外遗漏一个=。但是，即使在C / C ++世界。如果您碰巧正在编写Python代码，那么您一开始就不会受到那种讨厌的错字的影响，因为if a = 1在Python中是无效的。）
实际令人信服的理由assertEqual(expect, actual)是，您语言中的unittest库可能已经遵循了该命令来生成可读的错误消息。例如，在Python中，这样做时assertEqual(expected_dictionary, actual_dictionary)，unittest将显示实际带有前缀的缺失键-，以及带有前缀的额外键+，就像执行a一样git diff old_branch new_branch。

是否直观，这是坚持该assertEqual(expected, actual)命令的唯一最令人信服的理由。如果碰巧不喜欢它，那么您最好还是接受它，因为“实用性胜过纯度”。
最后，如果您需要一种帮助您记住顺序的方法，则此答案与assertEqual(expected_result, actual_calculation)赋值语句order相比result = calculate(...)。这可能是记忆实际行为的好方法，但是恕我直言，这不是直觉上令人信服的理由。

所以，你去。快乐assertEqual(expect, actual)！

Question 6

的一个别有用心的目的assertEqual()是为人类读者演示代码。因为最简单的函数调用是result = function(parameters)，所以习惯了想左边的返回值和右边的调用。

因此，记录函数的测试将在左侧显示一个文字，在右侧显示一个调用。

assertEqual(15, sum((1,2,3,4,5)))

即，（预期的，实际的）。与表达式类似。

assertEqual(4, 2 + 2)

如果您喜欢排队（尽管PEP8），则期望的参数有助于在左侧变短：

assertEqual(42, 2 * 3 * 7)
assertEqual(42, (1 << 1) + (1 << 3) + (1 << 5))
assertEqual(42, int('110', int('110', 2)))

_{感谢Andrew Weimholt和Ganesh Parameswaran提出的这些公式。}

Question 7

xUnit测试约定是预期的/实际的。因此，对于许多人来说，这是自然的顺序，因为那是他们所学的。

有趣的是，与xUnit框架的约定有所不同，qunit适用于实际/预期。至少使用javascript，您可以创建一个新函数来封装旧函数并将其分配给原始变量：

var qunitEquals = equals;
equals = function(expected, actual, message) {
    qunitEquals(actual, expected, message);
};

Question 8

我听到的解释是它来自TDD。

在“测试驱动开发”中，从测试开始，然后编写代码。

通过编写期望值开始断言，然后调用应该产生期望值的代码，是该思维定式的迷你版本。

当然，这可能只是人们讲的一个故事。不知道这是有意识的原因。