.net - ¿Es la herramienta Pex(generación de pruebas) realmente útil?

unit-testing code-generation

Question

Sí, es posible generar pruebas en valores de límite para funciones como "Suma" o "Dividir". Pex es una buena herramienta aquí.

Pero más a menudo creamos pruebas sobre el comportamiento empresarial. Consideremos un ejemplo del libro tdd de Beck clásico:

[Test]
public void ShouldRoundOnCreation()
{
  Money money = new Money(20.678);
  Assert.AreEqual(20.68,money.Amount);
  Assert.AreEqual(2068,money.Cents);
}

¿Se puede generar esta prueba? No :) El 95% de las pruebas en mis proyectos comprueban la lógica empresarial y no se pueden generar.

Pex (Especialmente en pareja con Moles) puede proporcionar una cobertura de código del 100%, pero una tasa de cobertura de código alta de un conjunto de pruebas nunca indica que el código está bien probado. Solo da una falsa confianza de que todo está probado. Y esto es muy peligroso.

Entonces, la pregunta es: ¿Es Pex una herramienta realmente útil?

Answer 1

Creo que está equivocado en la forma en que se debe usar Pex: recomendamos encarecidamente a los usuarios que escriban afirmaciones en sus pruebas unitarias parametrizadas.

Si escribe aserciones, Pex intentará invalidarlas sistemáticamente. Ahí es donde entra en juego el poder de Pex: cuanto más escriba las aserciones, más tratará de encontrar errores para usted.

Si usa Pex para obtener un conjunto de pruebas de alta cobertura de código sin escribir afirmaciones, solo obtiene lo que solicitó: cobertura de código y excepciones de tiempo de ejecución garantizadas. Pex ''only'' intenta cubrir ramas (1 aserción = 1 rama), si no hay ramas que cubrir (sin aserción), no generará casos de prueba interresting.

En general, escribir aserciones en pruebas unitarias parametrizadas es más difícil de escribir porque ... bueno, son más generales. Comencemos con el comportamiento de redondeo: ciertamente hay un límite en el que se permite que ocurra el redondeo, esto debería traducirse naturalmente en una prueba unitaria parametrizada:

[PexMethod]
public void RoundInBounds(double value) 
{
    var money = new Money(value);
    // distance between value and amount should be at most 0.01/2
    Assert.AreEqual(value, money.Amount, 0.005);
}

También hay una serie de patrones que se pueden utilizar para escribir esos. Por ejemplo, su clase de ''Dinero'' es probablemente idempotente: si devuelve el valor de ''Cantidad'' en una instancia de Dinero, obtendrá la cantidad de nuevo. Esto se traduce elegantemente en una prueba unitaria parametrizada:

[PexMethod]
public void RoundIsIdempotent(double value) 
{
     var first = new Money(value).Amount;
     var second = new Money(first).Amount;
     Assert.AreEqual(first, second, 0.0001);
}

Tenga en cuenta también que las pruebas unitarias parametrizadas pertenecen definitivamente al mundo TDD. Primero escriba primero la prueba de unidad parametrizada, Pex encontrará el error que falla, reparará el error, Pex encontrará el siguiente error, etc.

¿Esto hace de Pex una herramienta útil? Tú eres el juez.

Answer 2

Hay algunas cosas útiles en Pex.

1. Cobertura de código. Dejemos a un lado a Pex por un segundo. En general, una cobertura de código del 100% no significa necesariamente que tenga una buena cobertura de código. Simplemente significa que siempre se ejecuta la ruta, pero el programa tiene flujo de datos, y probar ese código diferente, entradas adicionales, le brinda la mejor "cobertura de prueba", si no la cobertura del código. Aquí, solo estoy reiterando tu punto. La cobertura del código al 100% no es necesariamente buena, pero puede estar seguro de que la cobertura del código del 25% es mala, por lo que es así como la cobertura del código es útil. Cuando tiene una cobertura de código bajo, está seguro de que tiene una cobertura de prueba baja.

   Cuando utiliza Pex para obtener una cobertura de código del 100%, no le ayuda realmente a obtener una mejor cobertura de prueba en sí misma, pero lo que sí hace es dar a cada parte del código de producción alguna prueba, que se puede usar para el depurador. De hecho, una presentación de Pex como conferencia muestra el uso de Pex para este propósito. El programador dijo: "Vaya, mire este método en NHibernate. Me gustaría recorrerlo en un depurador para ver qué hace, pero ¿cómo invoco ese método a través del" punto de entrada de negocios "normal en el ¿Biblioteca? Sin saber nada acerca de la biblioteca, no se puede. Entonces, corrió Pex y fue capaz de recorrer el código con todo tipo de parámetros. Interesante, Sí. Útil, tal vez, tal vez no.

2. Además de las pruebas creadas automáticamente, Pex también es útil para parametrizar sus pruebas. Es mucho mejor crear pruebas unitarias basadas en datos. Por qué escribir el mismo código una y otra vez, con diferentes parámetros. Escríbelo una vez y alimenta los parámetros desde una fuente de datos.

3. Pex también es útil como un simple marco de stubbing. Probablemente sea la forma más fácil de crear objetos simulados, utilizando la nueva expresión lambda, que es mucho más fácil de entender que los marcos complejos como RhinoMocks, etc. Con Moles, también puede apilar no solo la interfaz, sino métodos concretos no virtuales en las clases.

4. También tendría cuidado con la capa de "pruebas en la lógica de negocios", demasiado. Usted podría fácilmente llegar a hacer Behavioral Driven Development, que no es para pruebas de unidad. Allí, estás probando contra una especificación. Si eso es todo lo que hizo, ¿cómo probaría, diría, estructuras de datos personalizadas, etc., que no tienen valor comercial, pero son bibliotecas internas utilizadas en toda la aplicación?