.net - Prueba de unidad con contratos de código
c#-4.0 code-contracts (5)
Voy a estar en desacuerdo con otras personas aquí. Los contratos NO son pruebas, son afirmaciones sobre los requisitos y promesas de la API. No prueban mágicamente que tu código sea correcto, solo te brindan información en tiempo de ejecución cuando violas el contrato. No sé ustedes, pero odiaría enviar código que en algún rincón, el caso no cumplía con los contratos y se bloqueaba con una afirmación de contrato. Al igual que cualquier otro comportamiento, los contratos deben someterse a pruebas unitarias. Si no ejerce los contratos (y rutas de código que indirectamente ejercen los contratos) no tiene evidencia de la validez de los códigos. Los contratos de código y las pruebas unitarias no son conceptos mutuamente excluyentes.
¿Cuál es la recomendación de mejores prácticas para hacer TDD con los contratos de código de .NET 4.0?
Supongo que específicamente, mi pregunta es que dado que un punto de TDD es permitir que el código sea auto documentado y el contrato ahora proporciona una parte de la documentación, ¿los contratos de código deben probarse de la misma manera que otros códigos?
Esto depende de cómo usa contratos y qué tipo de aplicación está desarrollando.
Antes que nada: desde luego, no desea probar las afirmaciones y las postcondiciones ( Contract.Assert , Contract.Assume , Contract.Ensures y Contract.EnsuresOnThrow Vuelo) por separado. No veo ningún valor práctico al hacerlo, ya que el regrabador ya lo verificó durante el tiempo de ejecución, encontrará fallas muy rápidas incluso sin pruebas.
Sin embargo, en una aplicación bien probada, ninguna condición o afirmación posterior debería fallar, incluso en entradas no válidas. Por lo tanto, si todas sus pruebas (¡incluso las que prueban el manejo de datos no válidos!) Pasan sin una sola postcondición / aserción fallan, sus postcondiciones y aserciones pueden verse como "probadas".
Para esto, es posible que desee manejar el evento ContractFailed utilizando un "Assert.Fail" dentro de sus pruebas.
Ahora la parte "interesante" son las condiciones previas:
¿Estás desarrollando una biblioteca? Entonces, definitivamente debe probarlos si su tiempo / presupuesto lo permite (es peor no probar la lógica real).
Especialmente, si está utilizando la sobrecarga "Contract.Requires <E>" que arrojará una excepción específica en las fallas contractuales, debe probarlas como la validación regular de parámetros usando "if-throw" -constructs.
Si no está escribiendo una biblioteca, no diría que es realmente necesario probar las condiciones previas; no son un requisito comercial real, sino más bien un ayudante para la depuración.
Y puede ser realmente aburrido escribir una prueba unitaria para cada ArgumentNullException un método debería arrojar si un parámetro es null .
Si olvida este código de validación (es decir, el Contrato específico requerido) dentro de su método, probablemente también se olvide de la prueba unitaria. Por lo tanto, el valor adicional que un parámetro-validación-prueba aporta a su código (no de biblioteca) es muy bajo para el valor conectado.
Para resumir: no probar las postcondiciones y afirmaciones. Pruebe las condiciones previas, pero solo en las bibliotecas (y tal vez en partes de su código que se utilizan como bibliotecas).
Gran pregunta La respuesta simple es no. los contratos de código pueden encargarse de las pruebas superfluas que no se refieren al comportamiento del sistema. Si realmente puede obtener una cobertura del 100% del código, tendrá que encargarse de los controles ininteligibles, etc. estos controles no necesitan estar en su banco de pruebas. el beneficio adicional es que estos se verificarán en tiempo de compilación en lugar de esperar a que se ejecuten las pruebas.
Espero que esto ayude.
Una herramienta útil para crear pruebas unitarias en combinación con Contratos de código es Pex. Analiza su código y genera pruebas básicas de la unidad para ello. Lo mejor es que reconoce y entiende los contratos de código, y por lo tanto adapta el código de prueba que genera.
Si tiene una suscripción a MSDN, puede descargar Pex / Moles como herramienta de poder, de lo contrario, puede descargarla (no la versión más reciente) en http://research.microsoft.com/en-us/projects/pex/downloads. aspx .
Las pruebas están ahí para probar el código se comporta como se esperaba
NO deberías escribir pruebas explícitamente para ejercitar las afirmaciones del contrato.
Sin embargo, en TDD o al hacer un cambio de código, la ejecución de una prueba unitaria puede ejercer el código de una manera que hace que un contrato falle; cuando esto suceda la prueba debería fallar y usted necesita poder encontrar el contrato que falló rápidamente y fácilmente, para que pueda corregir el código.
Entonces, de alguna manera, quiere detectar una contracepción solo si hace un Asser.Fail ("No se cumple el requisito del contrato")
Esto puede ser más de lo que está buscando Cómo registrar un error al usar Contratos de código