debugging - tipos - junit software

¿Por qué los parámetros assertEquals() están en el orden(esperado, real)?

Question

¿Por qué tantos assertEquals() o una función similar toman el valor esperado como primer parámetro y el actual como segundo?
Esto me parece contrario a la intuición, ¿hay alguna razón particular para este orden inusual?

Answer 1

Estoy de acuerdo con el consenso de que la consistencia es # 1, pero el comportamiento de comparar diccionarios puede ser un punto de datos útil si está evaluando esta pregunta.

Cuando veo un "+" en un diff, leo esto como "el procedimiento que se está probando agregó esto". Nuevamente, se aplican las preferencias personales.

Nota: utilicé las teclas alfabéticas e hice que el diccionario fuera más largo, por lo que solo cambiaría una tecla del medio para mayor claridad del ejemplo. Otros escenarios muestran más diferencias difusas. También es digno de mención, assertEqual usa assertDictEqual en> = 2.7 y> = 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'',
            }
        )

Salida:

$ 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 2

La convención de prueba de xUnit es esperada / real. Entonces, para muchos ese es el orden natural ya que eso es lo que aprendieron.

Curiosamente, en un descanso de la convención para un marco xUnit, la qunidad va para real / esperado. Al menos con javascript puedes simplemente crear una nueva función que encapsula la anterior y asignarle la variable original:

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

Answer 3

Porque los autores tenían un 50% de posibilidades de igualar su intuición.

Debido a la otra sobrecarga

assertWhatever(explanation, expected, actual)

Y la explicación, que es parte de lo que sabes, va con lo esperado, que es lo que sabes, a diferencia de lo real, que no sabes en el momento de escribir el código.