2010-03-08 6 views
28

¿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?¿Por qué los parámetros assertEquals() están en el orden (esperado, real)?

+1

Esta es la razón por lo general terminan usando comparadores, tales como assertThat (reales, es (esperado)) Me resulta mucho más fácil de leer – JonathanC

+0

¿Estás seguro de que realmente es el orden? Los documentos no indican un estándar para 'assertEqual' sí mismo https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertEqual y la exploración de esa página muestra que el orden es inconsistente dentro del módulo unittest mismo . Pero este problema de Python implica (real, esperado) es, de hecho, el estándar: http://bugs.python.org/issue10573 –

+0

Además, tenga en cuenta que 'assertEquals' está en desuso - use' assertEqual' (aunque, al menos, en 2.7, en realidad no indica qué parámetro se espera y cuál es real) –

Respuesta

19

Porque los autores tenían un 50% de probabilidades de concordar con su intuición.

Debido a la sobrecarga de otra

assertWhatever(explanation, expected, actual) 

Y la explicación, que es parte de lo que sabe, va con la espera, que es lo que sabes, en contraposición a la actual, que no lo hace saber en el momento de escribir el código.

+9

Sin embargo, en ese caso, se vuelve ligeramente inconsistente porque en la mayoría de los idiomas, los parámetros necesarios aparecen primero y los obligatorios duran. Esta es la razón por la cual iría más naturalmente por assertWhatever (actual, esperado [, explicación]) – jor

+5

Lo siento, quise decir que los _optional_ aparecen últimos, no son obligatorios ... – jor

+2

Exactamente, jor! Además, es más común en condicionales escribir si (s == "a") en lugar de si ("a" == s) (aunque es debatible si sería mejor al revés - en términos de lo común, el primero uno gana sin embargo). – benroth

2

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

Interesantemente en un descanso de la convención para un marco xUnit qunit va para real/expected. Al menos con javascript que sólo puede crear una nueva función que encapsula el viejo y lo asigna la variable original:

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

Estoy de acuerdo con el consenso de que la consistencia es # 1, pero el comportamiento de los diccionarios que comparan puede ser una punto de datos útil si estás 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 cabe destacar, assertEqual uses 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', 
      } 
     ) 

de 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) 
Cuestiones relacionadas