Почему параметры assertEquals () находятся в порядке (ожидаемом, фактическом)?

Question

Почему многие assertEquals() или подобные функции принимают ожидаемое значение в качестве первого параметра, а фактическое значение - в качестве второго?
Это кажется мне нелогичным, так есть ли особая причина для этого необычного заказа?

Answer 1

Потому что у авторов был 50% шанс на совпадение с вашей интуицией.

Из-за другой перегрузки

assertWhatever(explanation, expected, actual)

И объяснение, которое является частью того, что вы знаете, соответствует ожидаемому, то есть тому, что вы знаете, в отличие от фактического, которое вы не знаете во время написания кода.

Answer 2

Я согласен с консенсусом, что согласованность является # 1, но поведение сравнения словарей может быть полезным назначением данных, если вы оцениваете этот вопрос.

Когда я вижу знак «+» на разнице, я читаю это как «проверяемая процедура добавила это». Опять же, личные предпочтения применяются.

Примечание. Я использовал алфавитные ключи и увеличил словарь, чтобы только средний ключ изменился для ясности примера. Другие сценарии отображают более запутанные различия. Также следует отметить, что assertEqual использует assertDictEqual в> = 2,7 и> = 3,1

exl.py

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)

Answer 3

Последней целью assertEqual() является демонстрация кода для читателей-людей. Поскольку самый простой вызов функции - result = function(parameters), человек привык думать о возвращаемом значении слева и справа .

Таким образом, тест, который документирует функцию, будет показывать литерал слева и вызов справа.

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

То есть (ожидаемый, фактический). Аналогично с выражением.

assertEqual(4, 2 + 2)

Answer 4

Соглашение о тестировании xUnit является ожидаемым / актуальным. Так что для многих это естественный порядок, так как это то, что они узнали.

Интересно, что в отказе от соглашения для платформы xUnit qunit соответствует фактическому / ожидаемому. По крайней мере, с помощью javascript вы можете просто создать новую функцию, которая инкапсулирует старую и присвоить ей исходную переменную:

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

Answer 5

Это очень интересная тема, и здесь очень много образовательных ответов!Вот то, чему я научился у них:

1. Интуитивно / противо-интуитивно можно считать субъективным, поэтому независимо от того, в каком порядке оно было первоначально определено, возможно, 50% из насне будь счастлив .

2. Лично я бы предпочел, чтобы оно было разработано как assertEqual(actual, expected), потому что, учитывая концептуальное сходство между assert и if, я бы хотелследует норма if actual == expect, например, if a == 1.

   (PS: верно, что существуют различные мнения, которые предлагает написать, если утверждение в«обратный порядок», то есть if(1==a) {...}, чтобы оградить вас от случайного пропуска одного =. Но этот стиль был далек от нормы, даже в мире C / C ++. И если вы пишетеКод Python, вы в первую очередь не подвержены этой неприятной опечатке, потому что if a = 1 недопустим в Python.)

3. Практическая убедительная причина сделать assertEqual(expect, actual), эточто библиотека unittest на вашем языке скорее всего ужепонижает этот порядок, чтобы генерировать читаемое сообщение об ошибке.Например, в Python, когда вы делаете assertEqual(expected_dictionary, actual_dictionary), unittest будет отображать пропущенные ключи с префиксом - и дополнительные ключи с префиксом +, так же, как когда вы делаете git diff old_branch new_branch.

   Интуитивно понятный или нет, это единственная наиболее убедительная причина придерживаться порядка assertEqual(expected, actual).Если вам это не нравится, вам лучше принять это, потому что «практичность побеждает чистоту» .

4. Наконец, если вам нужен способ помочь вам вспомнитьпорядок этот ответ сравнивает assertEqual(expected_result, actual_calculation) с порядком оператора присваивания result = calculate(...).Это может быть хорошим способом ЗАПОМНИТЬ де-факто поведение, но ИМХО это неоспоримое рассуждение о том, что порядок более интуитивен.

Итак, поехали.Happy assertEqual(expect, actual)!