unit testing - tipos - Contratos de código.NET 4.0: ¿cómo afectarán las pruebas unitarias?

pruebas unitarias php

Question

Por ejemplo, este article presenta.

¿Cuál es el beneficio?

El análisis estático parece genial, pero al mismo tiempo evitaría la capacidad de pasar nulo como parámetro en la prueba unitaria. (si siguió el ejemplo en el artículo)

Mientras que en el tema de las pruebas unitarias, dado cómo están las cosas ahora, seguramente no tiene sentido para los contratos de código si ya se practican las pruebas automatizadas.

Actualizar

Habiendo jugado con los Contratos de Código, estoy un poco decepcionado. Por ejemplo, basado en el código en la respuesta aceptada:

public double CalculateTotal(Order order)
{
    Contract.Requires(order != null);
    Contract.Ensures(Contract.Result<double>() >= 0);
    return 2.0;
}

Para las pruebas unitarias, aún debe escribir pruebas para asegurarse de que no se puede pasar el valor nulo, y el resultado es mayor o igual a cero si los contratos son de lógica comercial . En otras palabras, si tuviera que eliminar el primer contrato, no se romperían las pruebas, a menos que hubiera tenido una prueba específica para esta función. Esto se basa en no usar el análisis estático incorporado en las ediciones mejores (último etc.) de Visual Studio.

Esencialmente, todos se reducen a una forma alternativa de escribir declaraciones tradicionales. Mi experiencia en el uso de TDD con Code Contracts muestra por qué y cómo lo hice.

Answer 1

¿Cuál es el beneficio?

Digamos que quiere asegurarse de que un método nunca devuelva null . Ahora, con las pruebas unitarias, debe escribir un montón de casos de prueba donde llama al método con entradas variables y verifica que la salida no sea nula. El problema es que no puedes probar todas las entradas posibles.

Con los contratos de código, solo declara que el método nunca devuelve null . El analizador estático se quejará si no es posible demostrar eso. Si no se queja, usted sabe que su aseveración es correcta para todas las entradas posibles.

Menos trabajo, garantías perfectas de corrección. ¿Que es no gustar?

Answer 2

Bueno, no interferirá con las pruebas unitarias en general. Pero como vi, mencionaste algo sobre TDD.

Si lo pienso desde esa perspectiva, supongo que podría / podría cambiar el procedimiento del estándar.

• crear método (solo firma)
• crear prueba unitaria -> implementar la prueba
• ejecuta la prueba: deja que falle
• implementar el método, hackearlo hasta el final solo para hacerlo funcionar
• ejecutar la prueba: verlo pasar
• refactorizar su cuerpo de método (posiblemente desordenado)
• (Vuelve a ejecutar la prueba solo para ver que no has roto nada)

Este sería el procedimiento de pruebas unitarias con todas las funciones. En tal contexto, supongo que podría insertar contratos de código entre el 1 ° y el 2 ° punto, como

• crear método (solo firma)
• insertar contratos de código para los métodos parámetros de entrada
• crear prueba unitaria -> implementar la prueba
• ...

La ventaja que veo en este momento es que puede escribir pruebas de unidad más sencillas en el sentido de que no debería verificar todas las rutas posibles, ya que algunos ya se han tenido en cuenta en sus contratos definidos. Simplemente le da una verificación adicional, pero no reemplazaría las pruebas unitarias, ya que siempre habrá más lógica dentro del código, más camino que debe probarse con pruebas unitarias, como de costumbre.

Editar

Otra posibilidad que no consideré antes sería agregar los contratos de código en la parte de refactorización. Básicamente como una forma adicional de asegurar cosas. Pero eso de alguna manera sería redundante y dado que a la gente no le gusta hacer cosas redundantes ...

Answer 3

Los contratos le permiten decir cuál es el propósito real del código, en lugar de dejar que lo que haga el código con los argumentos aleatorios se le entregue como la definición desde el punto de vista del compilador o el siguiente lector del código. Esto permite un análisis estático y una optimización de código significativamente mejores.

Por ejemplo, si declaro un parámetro entero (usando la notación de contrato) para estar en el rango de 1 a 10, y tengo una matriz local en mi función declarada del mismo tamaño, que está indexada por el parámetro, el compilador puede decir que no hay posibilidad de error de subíndice, lo que produce un mejor código.

Puede indicar que nulo es un valor válido en un contrato.

El propósito de las pruebas unitarias es verificar dinámicamente que el código logre cualquier propósito declarado que tenga. El hecho de que haya escrito un contrato para una función no significa que el código lo haga, o que el análisis estático pueda verificar que el código lo haga. Las pruebas unitarias no desaparecerán.

Answer 4

No creo que las pruebas unitarias y los contratos interfieran tanto entre sí, y en todo caso los contratos deberían ayudar a las pruebas unitarias, ya que elimina la necesidad de agregar tediosas pruebas repetitivas para argumentos inválidos. Los contratos especifican el mínimo que puede esperar de la función, mientras que las pruebas unitarias intentan validar el comportamiento real de un conjunto particular de entradas. Considera este ejemplo artificial:

public class Order
{
    public IEnumerable Items { get; }
}

public class OrderCalculator
{
    public double CalculateTotal(Order order)
    {
        Contract.Requires(order != null);
        Contract.Ensures(Contract.Result<double>() >= 0);

        return 2.0;
    }
}

Claramente, el código satisface el contrato, pero aún necesitaría pruebas unitarias para validar que realmente se comporte como usted espera.