Cuando me burlo de los servicios dependientes para escribir casos de prueba de unidad para cualquier servicio java de nivel empresarial, encuentro que configurar los datos para los casos de prueba de unidad es un gran problema. La mayoría de las veces, esta es la razón más convincente para que los desarrolladores no escriban casos de prueba unitaria y escriban casos de prueba de estilo de integración. Si el servicio depende de un par de otros servicios (que dependen de sus respectivos DAO) y un DAO propio, se genera elwhen-thenReturn las cláusulas para un objeto razonablemente anidado se convierten en un gran esfuerzo y se ve que los desarrolladores toman la ruta fácil y cargan todo el contexto Spring y obtienen sus datos de fuentes directas, lo que no siempre proporciona la información que puede atravesar todas las rutas de código requeridas. Con esto en el fondo, un colega mío sugirió que, por qué no realizar una prueba de integración de muestra, y usar aspectos, capturar todos los puntos de datos relevantes y serializarlos a una representación XML que se puede usar para materializar los datos de prueba para la prueba de unidad. casos. Para nuestra grata sorpresa encontramos un marco denominadoTestDataCaptureJ en github que era muy similar a esto. Utilizó aspectos para capturar los puntos de datos y generó el código java para crear los objetos.

losmotivación indicado en el sitio parecía muy apropiado y me preguntaba si existen otras alternativas que puedan ofrecer características similares. Además, sería fantástico si los expertos pudieran criticar este enfoque general.

Además, el proyecto tiene aproximadamente 2 años de antigüedad y tiene algunos errores que tuvimos que solucionar y esperamos devolverlo como una bifurcación de github mavenizada. Solo verificando que no haya otra iniciativa similar de uno de los establos conocidos también.

¡Gracias por adelantado!