¿Es una mala práctica tener más de una afirmación en una prueba unitaria?[cerrado]

Question

¿Es una mala práctica tener más de una afirmación en una prueba unitaria?¿Importa?

Answer 1

A veces tengo exactamente un assert por caso de prueba, pero creo que más a menudo tengo varias declaraciones assert.

He visto el caso de que elude a @Arkain, donde una gran parte de código tiene un conjunto de pruebas de una sola unidad con sólo unos pocos casos de prueba, y todos ellos son testCase1, testCase2, etc etiquetados, y cada caso de prueba tiene cientos de asevera. Y aún mejor, cada condición por lo general depende de los efectos secundarios de la ejecución anterior. Siempre que la generación falla, invariablemente, en una prueba de unidad de este tipo, se necesita bastante tiempo para determinar dónde estaba el problema.

Sin embargo, el otro extremo es lo que su pregunta sugiere: un caso de prueba independiente para cada estado posible. Dependiendo de lo que se está probando, esto podría tener sentido, pero a menudo tengo varias asserts por caso de prueba.

Por ejemplo, si usted escribió java.lang.Integer, es posible que tenga algunos casos que parecen:

public void testValueOf() {
    assertEquals(1, Integer.valueOf("1").intValue());
    assertEquals(0, Integer.valueOf("0").intValue());
    assertEquals(-1, Integer.valueOf("-1").intValue());
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue());
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue());
    ....
}

public void testValueOfRange() {
    assertNumberFormatException("2147483648");
    assertNumberFormatException("-2147483649");
    ...
}

public void testValueOfNotNumbers() {
    assertNumberFormatException("");
    assertNumberFormatException("notanumber");
    ...
}
private void assertNumberFormatException(String numstr) {
    try {
        int number = Integer.valueOf(numstr).intValue();
        fail("Expected NumberFormatException for string \"" + numstr +
             "\" but instead got the number " + number);
    } catch(NumberFormatException e) {
        // expected exception
    }
}

Algunas reglas simples que se me ocurre de la mano fuera de cuántos aserción de que poner en un caso de prueba:

• ¿No tiene más de un assert que depende de los efectos secundarios de la ejecución anterior.
• Grupo asserts juntos que ponen a prueba la misma función / característica o faceta de la misma -. hay necesidad de que la sobrecarga de múltiples casos de prueba unidad cuando no es necesario
• Cualquiera de las reglas anteriores debe ser anulado por la practicidad y sentido común. Es probable que no quiere un millar de casos de prueba con una sola unidad de aserción en cada una (o incluso varios afirma) y no desea que un caso de prueba individual con cientos de declaraciones assert.

Answer 2

No, no es una mala práctica. Si el método que se está probando devuelve una clase, debe probar las diferentes variables que deberían estar definidas. Para este propósito que también podría utilizar una unidad de prueba.

Sin embargo, si usted está probando varias características en una unidad de prueba, no va a ser tan claro cuando se produce un error que cuenta la causa del problema. Recuerde que las pruebas unitarias son de su amigo, así que permita que le ayuden. Que sea de fácil acceso para ver lo que salió mal para que pueda ir solucionarlo.

Answer 3

Sus pruebas unitarias deben ser razonablemente grano fino. Por lo general, cuanto menor afirma, es más probable que su prueba es apuntar a una función específica y no mezclar las pruebas para múltiples funciones en la misma prueba. ¿Esto significa que todas las pruebas sólo deben tener un afirman? No, pero yo lo consideraría un "olor a prueba" si he encontrado varias afirma, lo que podría probar varias cosas en la misma unidad de prueba. Esto se debe manejar "olor" como lo haría un olor código y refactorizar la prueba para refinarlo para que sólo pone a prueba una "cosa" -. Incluso si requiere más de un afirman

Por ejemplo, estoy haciendo un proyecto de MVC y ahora una de las pruebas que escribo es que la visión correcta se representa por la acción. De hecho, podría haber varios de estos si diferentes rutas de código pueden dar lugar a diferentes puntos de vista. Así es como yo lo defino ser el punto de vista correcto: el resultado es el tipo correcto y tiene el nombre correcto. Esto requiere dos afirma, pero yo sólo estoy probando una cosa.

var result = controller.Action() as ViewResult;

Assert.IsNotNull( result );
Assert.AreEqual( viewName, result.ViewName );

Yo podría hacer algo similar con el modelo, pero no me gustaría probar que el modelo es correcto en la misma prueba que la comprobación de la vista debido a que estos son diferentes aspectos del comportamiento del código. Podría cambiar el modelo o ver esperada y poniéndolo en un ensayo separado, sólo aquellas pruebas que se ocupan de esa característica del método que haya que cambiar.

Answer 4

Para mí es muy común tener más de una afirmación en una prueba unitaria.Por lo general, hago una afirmación de una condición previa y luego una afirmación de la condición posterior esperada.

Considerar:

assert(list.isEmpty());

FetchValues(list);

assert(list.count == expectedItemCount);

AssertValuesMatch(list,expectedValues);

Sí, podría dividir las dos condiciones posteriores en dos pruebas, pero dependiendo del costo de FetchValues ​​podría ralentizar innecesariamente el proceso general de prueba.

Answer 5

No me considero una mala práctica. Las pruebas unitarias pueden hacer lo que quieran:. valer, ingrese a archivos, enviar mensajes SMS insultantes a la gestión, nada

El posible problema es que la complejidad añadida puede cambiar el comportamiento del programa que se está probando, pero eso es raramente el caso si usted está teniendo cuidado de, y puede ser descubierto de todos modos.

Answer 6

Puesto en toda la afirma en la que desea. En serio.

Trato de hacer valer cada paso del camino hasta e incluyendo el objetivo específico de mi prueba.

Answer 7

Debería definitivamente el uso de sólo una aserción en el método de ensayo! El uso de muchos afirma puede ser el olor de código que se está probando más de una cosa. Por otra parte, existe la posibilidad de que alguien pueda añadir nueva afirman en su prueba en vez de escribir otro. Y ¿cómo se puede entender como su otra asevera completado cuando el primero no?

También puede encontrado interesante este artículo: https: / /timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/

Answer 8

No importa. Lo único que importa es que las pruebas unitarias cubrirán todos los errores posibles.

Este es un ejemplo de "sobre-pensamiento".

Answer 9

A "Unidad de prueba" debe probar 1 unidad, así que sea lo más pequeño posible y prueba sólo 1 cosa determinada. Yo sugeriría tener sólo 1 aserción

Pero creo que está bien tener 2 afirmaciones siempre que no están uno detrás del otro.

Mal ejemplo

public void ValidateRulesEntry_Valid_ValidConditionsFromFile()
{
    string condition = "Target.HasValue";
    string returnMessage;

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage);


    Assert.IsTrue(successFul);
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage));
    Assert.IsTrue(returnMessage == "OK");

}