¿Debería ser "Organizar-Afirmar-Actuar-Afirmar"?

Con respecto al patrón de prueba clásico de Arrange-Act-Assert , con frecuencia me encuentro agregando una contraafirmación que precede a Act. De esta manera sé que la afirmación pasajera realmente pasa como resultado de la acción.

Lo considero análogo al rojo en red-green-refactor, donde solo si he visto la barra roja en el curso de mis pruebas, sé que la barra verde significa que he escrito un código que marca la diferencia. Si escribo una prueba satisfactoria , cualquier código la satisfará; De manera similar, con respecto a Arrange-Assert-Act-Assert, si mi primera afirmación falla, sé que cualquier Ley habría pasado la Afirmación final, por lo que en realidad no verificaba nada sobre la Ley.

¿Sus pruebas siguen este patrón? ¿Por qué o por qué no?

Aclaración de actualización : la afirmación inicial es esencialmente lo opuesto a la afirmación final. No es una afirmación de que Arrange funcionó; es una afirmación de que Act aún no ha funcionado.

Esto no es lo más común, pero lo suficientemente común como para tener su propio nombre. Esta técnica se llama Aserción de guardia . Puede encontrar una descripción detallada en la página 490 en el excelente libro xUnit Test Patterns de Gerard Meszaros (muy recomendable).

Normalmente, no uso este patrón yo mismo, ya que me parece más correcto escribir una prueba específica que valide cualquier condición previa que sienta la necesidad de asegurar. Tal prueba siempre debería fallar si falla la condición previa, y esto significa que no la necesito incrustada en todas las demás pruebas. Esto proporciona un mejor aislamiento de las preocupaciones, ya que un caso de prueba solo verifica una cosa.

Puede haber muchas condiciones previas que deban cumplirse para un caso de prueba determinado, por lo que es posible que necesite más de una afirmación de guardia. En lugar de repetirlos en todas las pruebas, tener una (y solo una) prueba para cada condición previa mantiene su código de prueba más sostenible, ya que tendrá menos repetición de esa manera.

También podría especificarse como Organizar- Supongamos -Ley-Assert.

Hay un control técnico para esto en NUnit, como en el ejemplo aquí: http://nunit.org/index.php?p=theory&r=2.5.7

He aquí un ejemplo.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

Podría ser que escribiera Range.includes()simplemente para devolver la verdad. No lo hice, pero puedo imaginar que podría haberlo hecho. O podría haberlo escrito mal de muchas otras formas. Esperaría y esperaría que con TDD lo hiciera bien, queincludes() lo hiciera simplemente funciona, pero tal vez no lo hice. Entonces, la primera afirmación es una verificación de cordura, para garantizar que la segunda afirmación sea realmente significativa.

Leído por sí mismo, assertTrue(range.includes(7));está diciendo: "afirmar que el rango modificado incluye 7". Si se lee en el contexto de la primera afirmación, dice: "afirmar que invocando abarcar () hace que incluya 7. Y como abarcar es la unidad que estamos probando, creo que tiene algún (pequeño) valor.

Estoy aceptando mi propia respuesta; muchos otros malinterpretaron mi pregunta como si se tratara de probar la configuración. Creo que esto es un poco diferente.

Una Arrange-Assert-Act-Assertprueba siempre se puede refactorizar en dos pruebas:

1. Arrange-Assert

y

2. Arrange-Act-Assert

La primera prueba solo afirmará lo que se configuró en la fase Organizar, y la segunda prueba solo confirmará lo que sucedió en la fase Actuar.

Esto tiene la ventaja de brindar una retroalimentación más precisa sobre si es la fase de Arreglo o la de Actuar la que falló, mientras que en el original Arrange-Assert-Act-Assertse combinan y tendría que profundizar y examinar exactamente qué afirmación falló y por qué falló para saber si fue el Acuerdo o el Acto el que falló.

También satisface mejor la intención de realizar pruebas unitarias, ya que separa la prueba en unidades independientes más pequeñas.

Por último, tenga en cuenta que siempre que vea secciones Organizar similares en una prueba diferente, debe intentar extraerlas en métodos auxiliares compartidos, para que sus pruebas sean más SECAS y más fáciles de mantener en el futuro.

Ahora estoy haciendo esto. AAAA de un tipo diferente

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

Ejemplo de prueba de actualización:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

La razón es que el ACT no contiene la lectura del ReadUpdated porque no forma parte del acto. El acto solo cambia y ahorra. Entonces, realmente, ARRANGE ReadUpdated para aserción, estoy llamando a ASSEMBLE para aserción. Esto es para evitar confundir la sección ARRANGE

ASSERT solo debe contener afirmaciones. Eso deja ASSEMBLE entre ACT y ASSERT, lo que configura la aserción.

Por último, si está fallando en el Arrange, sus pruebas no son correctas porque debería tener otras pruebas para prevenir / encontrar estos errores triviales . Porque para el escenario que presento, ya debería haber otras pruebas que prueben READ y CREATE. Si crea una "Aserción de guardia", puede estar interrumpiendo DRY y creando mantenimiento.

Lanzar una afirmación de "comprobación de cordura" para verificar el estado antes de realizar la acción que está probando es una técnica antigua. Por lo general, los escribo como andamios de prueba para demostrarme a mí mismo que la prueba hace lo que espero y los elimino más tarde para evitar saturar las pruebas con andamios de prueba. A veces, dejar el andamio ayuda a que la prueba sirva como narrativa.

Ya leí acerca de esta técnica, posiblemente de usted por cierto, pero no la uso; principalmente porque estoy acostumbrado a la forma triple A para mis pruebas unitarias.

Ahora, tengo curiosidad y tengo algunas preguntas: ¿cómo escribe su prueba, hace que esta afirmación falle, siguiendo un ciclo de refactorización rojo-verde-rojo-verde, o la agrega después?

¿Fallas a veces, quizás después de refactorizar el código? Qué te dice esto ? Quizás podría compartir un ejemplo en el que ayudó. Gracias.

He hecho esto antes al investigar una prueba que falló.

Después de un considerable rascado de cabeza, determiné que la causa era que los métodos llamados durante "Organizar" no funcionaban correctamente. El fracaso de la prueba fue engañoso. Agregué una afirmación después del arreglo. Esto hizo que la prueba fallara en un lugar que resaltaba el problema real.

Creo que también hay un olor a código aquí si la parte Arrange de la prueba es demasiado larga y complicada.

En general, me gusta mucho "Organizar, actuar, afirmar" y lo uso como mi estándar personal. Sin embargo, lo único que no me recuerda que haga es desordenar lo que he arreglado cuando se hacen las afirmaciones. En la mayoría de los casos, esto no causa mucha molestia, ya que la mayoría de las cosas desaparecen automáticamente a través de la recolección de basura, etc. Sin embargo, si ha establecido conexiones con recursos externos, probablemente querrá cerrar esas conexiones cuando haya terminado. con sus afirmaciones o muchos tienen un servidor o recurso costoso en algún lugar que se aferra a conexiones o recursos vitales que debería poder regalar a otra persona. Esto es particularmente importante si está uno de esos desarrolladores que no usa TearDown o TestFixtureTearDownpara limpiar después de una o más pruebas. Por supuesto, "Organizar, actuar, afirmar" no es responsable de que no cierre lo que abro; ¡Solo menciono este "gotcha" porque todavía no he encontrado un buen sinónimo de "A-word" para "disponer" para recomendar! ¿Alguna sugerencia?

Eche un vistazo a la entrada de Wikipedia sobre Diseño por contrato . La Santísima Trinidad Arrange-Act-Assert es un intento de codificar algunos de los mismos conceptos y se trata de demostrar la corrección del programa. Del artículo:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

Existe una compensación entre la cantidad de esfuerzo invertido en configurar esto y el valor que agrega. AAA es un recordatorio útil de los pasos mínimos requeridos, pero no debe disuadir a nadie de crear pasos adicionales.

Depende de su entorno / idioma de prueba, pero generalmente si algo falla en la parte Arrange, se lanza una excepción y la prueba falla al mostrarlo en lugar de iniciar la parte Act. Entonces no, generalmente no uso una segunda parte de Assert.

Además, en el caso de que su parte Arrange sea bastante compleja y no siempre arroje una excepción, tal vez podría considerar envolverla dentro de algún método y escribir una prueba propia para ella, para que pueda estar seguro de que no fallará (sin lanzar una excepción).

No uso ese patrón, porque creo que hacer algo como:

Arrange
Assert-Not
Act
Assert

Puede ser inútil, porque supuestamente sabe que su parte Arrange funciona correctamente, lo que significa que todo lo que está en la parte Arrange debe probarse también o ser lo suficientemente simple como para no necesitar pruebas.

Usando el ejemplo de su respuesta:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

Si realmente quieres probar todo en el ejemplo, prueba más pruebas ... como:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

Porque, de lo contrario, se pierden muchas posibilidades de error ... por ejemplo, después de abarcar, el rango solo incluye 7, etc. También hay pruebas para la longitud del rango (para asegurarse de que no abarque también un valor aleatorio), y otro conjunto de pruebas completamente para tratar de abarcar 5 en el rango ... ¿qué esperaríamos: una excepción en el abarcamiento o que el rango no se altere?

De todos modos, el punto es que si hay alguna suposición en el acto que desea probar, póngala en su propia prueba, ¿no?

Yo suelo:

1. Setup
2. Act
3. Assert 
4. Teardown

Porque una configuración limpia es muy importante.