Pruebas unitarias: ¿por qué el argumento esperado siempre es primero en las pruebas de igualdad?

Question

¿Por qué es que cada marco de pruebas de unidad (no conozco :) requiere que el valor esperado de tests de igualdad es siempre el primer argumento:

Assert.AreEqual(42, Util.GetAnswerToLifeTheUniverseAndEverything()); 

assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything()); 

etc.

estoy bastante acostumbrado a ella ahora, pero cada codificador que intento enseñar pruebas unitarias comete el error de invertir los argumentos, lo cual entiendo perfectamente. Google no ayudó, ¿tal vez uno de los evaluadores de unidades de núcleo duro aquí sabe la respuesta?

Answer 1

creo que es sólo una convención ahora y como usted ha dicho que es adoptado por "cada marco de pruebas de unidad (no conozco)". Si está utilizando un marco, sería molesto cambiar a otro marco que use la convención opuesta. Entonces (si está escribiendo un nuevo marco de prueba de unidades, por ejemplo) sería preferible que usted también siga la convención existente. Creo que esto proviene de la forma en que algunos desarrolladores prefieren escribir sus tests de igualdad:

if (4 == myVar) 

Para evitar cualquier asignación no deseado, por error, escribir un "=" en lugar de "==". En este caso, el compilador detectará este error y evitará muchos problemas al intentar solucionar un extraño error de tiempo de ejecución.

Answer 2

Nadie lo sabe y es la fuente de confusiones interminables. Sin embargo no todos los marcos siguen este patrón (a una mayor confusión):

1. FEST-Assert utiliza normal de orden:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything()).isEqualTo(42); 
   

2. Hamcrest:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything(), equalTo(42)) 
   

3. ScalaTest no realmente hacer una distinción:

   Util.GetAnswerToLifeTheUniverseAndEverything() should equal (42) 
   

Answer 3

No sé, pero he sido parte de varias discusiones animadas sobre el orden de los argumentos para las pruebas de igualdad en general.

Hay una gran cantidad de personas que piensan

if (42 == answer) { 
    doSomething(); 
} 

es preferible

if (answer == 42) { 
    doSomething(); 
} 

en lenguajes basados ​​en C. La razón de esto es que si se pone accidentalmente un solo signo igual:

if (42 = answer) { 
    doSomething(); 
} 

le dará un error de compilación, pero

if (answer = 42) { 
    doSomething(); 
} 

podría no, y sin duda introducir un error que podría ser difícil para localizar a. Entonces, quién sabe, tal vez la persona/personas que establecieron el marco de pruebas unitarias estaban acostumbradas a pensar en pruebas de igualdad de esta manera, o copiaban otros marcos de pruebas unitarias que ya estaban configurados de esta manera.

Answer 4

Creo que es porque JUnit fue el precursor de la mayoría de los marcos de pruebas de unidades (no es que fuera el primer marco de pruebas unitarias, pero provocó una explosión en las pruebas unitarias). Como JUnit lo hizo de esa manera, todos los marcos posteriores copiaron esta forma y se convirtió en una convención.

¿por qué JUnit lo hizo de esa manera? No lo sé, pregúntale a Kent Beck.

Answer 5

Parece que la mayoría de los marcos primeros utilizan espera antes real (por alguna razón desconocida, sin embargo, tirada de dados, tal vez?). Sin embargo, con el desarrollo de lenguajes de programación, y aumentó la fluidez del código, esa orden se revirtió. La mayoría de las interfaces fluidas generalmente intentan imitar el lenguaje natural y los marcos de prueba de unidades no son diferentes.

En la afirmación, queremos asegurar que algún objeto coincide con algunas condiciones. Esta es la forma de lenguaje natural, como si tuviera que explicar su código de prueba que probablemente diría

"En esta prueba, me aseguro de que el valor calculado es igual a 5"

vez de

"En esta prueba, me aseguro de que 5 sea igual al valor calculado".

La diferencia puede no ser enorme, pero vamos a seguir adelante. Considere esto:

Assert.That(Roses, Are(Red)); 

Sonidos acerca de la derecha. Ahora:

Assert.That(Red, Are(Roses)); 

Hm ..? Probablemente no se sorprenda si alguien le dijera que las rosas son rojas. Por otro lado, rojo son rosas, plantea preguntas sospechosas. Yoda, alguien?

Yoda de hacer un punto importante - Orden inverso obliga a think.

Se hace aún más poco natural cuando sus afirmaciones son más complejos:

Assert.That(Forest, Has.MoreThan(15, Trees)); 

¿Cómo le revertir ese? Más de 15 árboles están siendo ocupados por el bosque?

Esta afirmación (fluidez como un factor determinante para la modificación) se refleja de alguna manera en el cambio que ha pasado por NUnit - originalmente (Assert.AreEqual) se utiliza espera antes real (estilo antiguo). Las extensiones fluidas (o para usar la terminología de NUnit, basada en restricciones - Assert.That) revirtieron ese orden.

Answer 6

Bueno, tenían que elegir una convención. Si quieres revertirlo, prueba los adaptadores Hamcrest. Están destinados a ayudar a aumentar la legibilidad. Aquí hay una muestra básica:

import org.junit.Test; 
import static org.junit.Assert.assertThat; 
import static org.hamcrest.core.Is.is; 

public HamcrestTest{ 
    @Test 
    public void matcherShouldWork(){ 
     assertThat( Math.pow(2, 3), is(8) ); 
    } 
} 

Answer 7

Seguramente tiene sentido lógico poner primero el valor esperado, ya que es el primer valor conocido.

Piénselo en el contexto de las pruebas manuales. Una prueba manual tendrá el valor esperado escrito, con el valor real registrado posteriormente.

Answer 8

Porque, desafortunadamente, no muchos programadores han leído Self-Reliance by Ralph Waldo Emerson.