Tengo una jerarquía de clases Java formada por una clase abstracta y N extensiones de la misma. En la clase abstracta tengo un método que está anotado con una anotación @Remove. Si bien no obtendremos ninguna excepción de no fallará rápidamente si se elimina esta anotación, es posible que salgamos de las excepciones de memoria, por lo que me gustaría estar seguro de que notaremos lo más rápido posible si esta anotación desaparece en alguna refactorización.
Estoy tratando de crear GUTS (buenas pruebas unitarias), así que pensé que podría documentar este "requisito técnico" en mis pruebas, con un caso de prueba que lo indique.
Pero esta no es una característica, es un detalle de implementación y no está vinculada al comportamiento del método (el método podría estar vacío, pero tiene que existir y debe ser anotado).
¿Está bien crear una prueba para eso o hay alguna otra forma de verificar la existencia de esta anotación?
fuente
Respuestas:
Sí, crea una prueba unitaria. Está diciendo que si se elimina la anotación, puede salir de los errores de memoria en la producción. Eso sería un error mortal. Dejar que eso suceda debido a alguna idea de que las pruebas de alguna manera deberían ser limitadas es contraproducente. Las pruebas deben verificar la corrección en todos los sentidos. Cuanto antes detecte el posible problema, mejor será tener una prueba unitaria y fallar la compilación de CI es la forma sólida de evitar el error. No parece que valga la pena intentar inventar otro mecanismo para evitar la introducción de dicho error. Cada nuevo desarrollador tendrá que recibir una explicación de cómo manejar el "caso especial" de ninguna prueba de corrección funcional. Lo más probable es que no sea un buen uso del tiempo del desarrollador.
Es probable que los equipos de edición que realizan BDD separen las pruebas funcionales empresariales de las pruebas técnicas, como las pruebas de rendimiento. Por lo general, los equipos tienen diferentes tipos de pruebas, incluidas las pruebas de integración que se ejecutan con menos frecuencia que sus pruebas de lógica empresarial principales. Esto generalmente se hace con perfiles de compilación para que los desarrolladores en su flujo puedan ejecutar pruebas rápidas de lógica de negocios con frecuencia y las pruebas de integración más lentas antes de comprometer el código. La compilación de CI ejecutará todas las pruebas.
fuente
Cuando se implementa una función crítica usando una técnica declarativa como esta, tiendo a preferir usar una prueba de integración que incluya la parte del marco que reconoce la declaración. Esto lo protege de cambios en el comportamiento de los marcos, malentendidos sobre el efecto de la declaración, etc. Simplemente probar la presencia de la anotación no garantiza ningún comportamiento específico.
fuente