Let&s habla de algunos conceptos erróneos populares sobre las afirmaciones.
El código de producción debe ser ejecutado con las afirmaciones encendidas
Las aseveraciones son una herramienta de tiempo de desarrollo para fines de prueba solamente . No están pensadas para entornos de producción. Validan sus suposiciones para ayudar a los desarrolladores a prevenir errores en el futuro.
¿Por qué la suposición no se cumplió cuando se probó esto o se realizó aquello? Responde a esta pregunta, encuentra la causa raíz y arréglala. Pero hágalo en las etapas de desarrollo. El punto de usar afirmaciones es prevenir que esos errores ocurran cuando el código de tiempo se vuelva productivo.
Además, recuerda que no debemos usar afirmaciones para manejar errores… lo que me lleva al siguiente error.
En lugar de afirmar una condición, puedes lanzar una excepción de tiempo de ejecución
A veces sí, puedes hacer una excepción en lugar de usar una afirmación. De hecho, las aseveraciones se construyen sobre las excepciones y un AssertionError puede ser capturado como cualquier otra excepción de Java (no es que debamos hacerlo).
Pero existen casos en los que no se puede sustituir una afirmación por una excepción.
Una vez más, las afirmaciones tienen un propósito distinto de las excepciones. Tienen por objeto poner a prueba las suposiciones y detectar errores. Mientras tanto, las excepciones indican condiciones excepcionales – problemas de los que el desarrollador puede no haber dado cuenta.
Puede utilizar afirmaciones para las comprobaciones lógicas internas dentro de su código, excepciones no comprobadas para condiciones de error fuera de su código inmediato's control, y excepciones comprobadas para negocios y errores recuperables.
No olvide que las afirmaciones pueden habilitarse o deshabilitarse (globalmente o para paquetes o clases individuales).
Por ejemplo, puedes empezar usando una suposición para comprobar que el flujo de ejecución no llega a un punto determinado de tu programa:
<pre>12345678910111213switch(type){case1://…break;case2://…break;case3://…break;default:assertfalse:"Caso por defecto alcanzado";}</pre>
java
Lo que equivale a:
<pre>12345678910111213switch(type){case1://…break;case2://…break;case3://…break;default:thrownewAssertionError("Default case reached");}</pre>
java
Pero con la ventaja de tener la opción de deshabilitar el lanzamiento de la excepción.
Y, al igual que con los mensajes de afirmación personalizables, es mejor práctica utilizar excepciones significativas siempre que sea posible:
<pre>12345678910111213switch(type){case1://…break;case2://…break;case3://…break;default:thrownewIllegalStateException("Tipo ilegal: "+ type);}</pre>
java
Las pruebas unitarias son sustitutos de las afirmaciones
De alguna manera, las declaraciones de afirmación sirven como pruebas de su código. Sin embargo, las pruebas de unidad no deben sustituir a las afirmaciones y las afirmaciones no deben sustituir a las pruebas de unidad. En su lugar, las declaraciones de afirmación pueden complementar sus pruebas de unidad.
Las aseveraciones validan las suposiciones sobre el estado interno de su programa – cosas como las precondiciones, post-condiciones e invariantes.
Por el contrario, las pruebas de la unidad comprueban el comportamiento externo de su programa. Generalmente, siguen la estructura Arreglar-actuar-afirmar . Es decir, establecen las condiciones previas (don't testearlas), realizan la operación y afirman el resultado; todo ello desde una perspectiva externa de la clase o método que se está probando.
Sí, puede haber alguna superposición entre ellos. Las afirmaciones de las pruebas unitarias pueden ser las mismas que las afirmaciones posteriores a las condiciones, pero tienen propósitos diferentes.
Hay un límite de lo que se puede hacer con las declaraciones de afirmación. Las pruebas unitarias proporcionan más flexibilidad y tienen un mayor alcance que las aseveraciones, ya que se adaptan específicamente a determinadas tareas. De hecho, las pruebas unitarias a menudo impulsan el proceso de desarrollo de software, como se ve en el modelo de desarrollo impulsado por pruebas.