¿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)?
Respuesta
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.
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
Lo siento, quise decir que los _optional_ aparecen últimos, no son obligatorios ... – jor
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
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);
};
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)
- 1. ¿Por qué los parámetros de `atan2`" están hacia atrás "?
- 2. ¿Por qué el orden de evaluación para los parámetros de función no se especifica en C++?
- 3. ¿Dónde están los 'parámetros del mapa' en el conjunto NoHandlerFoundException?
- 4. Convenciones para el orden de los parámetros en una función
- 5. ¿Están garantizados los parámetros de matriz en los rieles en el orden en que aparecen en la url?
- 6. ¿Por qué los bits de un std :: bitset están en orden inverso?
- 7. .NET regex no captura en el orden esperado
- 8. ¿Por qué los tipos de parámetros contravariantes en Java no están permitidos para la anulación?
- 9. ¿Por qué están prohibidos los comentarios anidados?
- 10. ¿Por qué debería inicializar las variables de miembro en el orden en que están declaradas?
- 11. ¿Por qué Scala no infiere completamente los parámetros de tipo cuando los parámetros de tipo están anidados?
- 12. ¿El orden de ejecución de los parámetros garantiza en Java?
- 13. Pruebas unitarias: ¿por qué el argumento esperado siempre es primero en las pruebas de igualdad?
- 14. assertEquals JUnit() falla por dos objetos
- 15. ¿Por qué los parámetros se comportan así?
- 16. ¿Por qué los inicializadores designados no están implementados en g ++
- 17. Hacer que PostgreSQL respete el orden de los parámetros ingresados?
- 18. ¿Por qué los nombres de dominio están al revés?
- 19. assertEquals vs. assertEqual en python
- 20. Java Generics - Esperado tipo de retorno diferente a la real
- 21. ¿Por qué mis pruebas funcionales están fallando?
- 22. ERROR: "Error de sintaxis en token"; ",, esperado" ¿Por qué?
- 23. ¿Por qué el orden de JIT afecta el rendimiento?
- 24. Memcache + PHP - ¿Por qué los datos no están expirando?
- 25. ¿Por qué los tipos de datos algebraicos Haskell "están cerrados"?
- 26. ¿Por qué los controles están en el lugar incorrecto si están posicionados mientras se desplaza el formulario?
- 27. ¿Por qué los elementos de Stellar.js no se están moviendo?
- 28. ¿Por qué ciertos parámetros tienen el prefijo "A" en Delphi?
- 29. ¿Por qué los OODBMS no están tan extendidos como RDBMS?
- 30. Los datos de JSON están entre corchetes ¿Por qué?
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
¿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 –
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) –