angularjs - style - ng-class

¿Cómo detectar modificaciones de API al burlarse de las pruebas de e2e?

Question

Me gustaría configurar una base de prueba de e2e sólida en el proyecto de nuestro equipo, pero no puedo encontrar una solución simple a esa pregunta:

Cuando se burla de todas sus llamadas, ¿cuál es la mejor manera de detectar si se modificó el modelo real de los objetos devueltos por su servidor?

Sus pruebas aún pasarían porque están probando una versión obsoleta del modelo, pero la aplicación está potencialmente rota.

Por ejemplo, si un simulacro asume que /api/users/1 devuelve null si el usuario no existe, cuando realmente devuelve un objeto vacío, aunque las pruebas puedan pasar, el comportamiento que se prueba se basa en suposiciones incorrectas y, por lo tanto, puede fallar de maneras inesperadas.

¿O quizás el back-end de alguna manera está proporcionando archivos json estáticos con el último modelo actualizado y el frontend se basa en esto?

Esto, por supuesto, supone que las personas que trabajan en el back-end y las personas que trabajan en la interfaz son equipos separados.

Estoy usando Angular 1.xy Transportador aquí, pero esto realmente no depende de la tecnología.

Answer 1

Creo que lo que estás haciendo (aislamiento frontend durante las pruebas) es correcto, mantenlo de esta manera.

Lo que puedes hacer para verificar tus burlas es una de esas:

1) Si frontend y backend están estrechamente relacionados y desarrollados juntos, agregue un conjunto de pruebas unitarias para el back-end para verificar las respuestas de la API. De esta forma, si algo cambia en la API, las pruebas de back-end fallarán y usted sabrá que los simulacros frontend deberían actualizarse también.

Durante el desarrollo, puede ejecutar ambos conjuntos de pruebas (e2e y backend unit tests) periódicamente o incluso en cada cambio de código.

2) Si frontend es más o menos independiente del back-end, entonces necesita tener algunas pruebas de integración, que ejecutará además de las pruebas de e2e. Estos deberían realizar solicitudes HTTP reales al backend y comparar la estructura de datos devuelta con sus simulaciones. De esta forma puede detectar la situación cuando los simulacros se vuelvan obsoletos.

El segundo enfoque es más confiable, pero las pruebas de integración probablemente serán más lentas que las pruebas unitarias de back-end, por lo que puede ejecutarlas automáticamente solo en el servidor de CI y no durante el desarrollo local.

Answer 2

window.e2eHttp[request.url] = null; registrar un interceptor http que almacena los datos a petición: window.e2eHttp[request.url] = null; , response + responseError: window.e2eHttp[request.url] = result;

Puede usar el sistema de módulo angular del transportador para inyectar o usar una bandera en su solución, e2eService.isEnabled() , para activar y desactivar el interceptor.

Luego, en su prueba e2e, debe implementar un browser.wait + browser.executeScript window.e2eHttp[request.url] browser.wait + browser.executeScript hasta que window.e2eHttp[request.url] tenga datos. Siempre tendrá un objeto de respuesta http angular (encabezados de estado http, datos, etc.)

Answer 3

Una solución similar a @Lablanc Meneses sería guardar la respuesta de cada llamada en un archivo JSON. Guarde su respuesta dentro del interceptor para sus pruebas e2e y luego use el archivo JSON guardado para las pruebas e2e. Estas llamadas JSON se actualizarán automáticamente cada vez que ejecute su servicio de API. esto requeriría ejecutar todos sus servicios una vez para almacenar el modelo por primera vez y luego usarlo para sus pruebas de e2e. El modelo se actualizará tan pronto como ejecute su API actualizada. puede crear un alternar para dejar de guardar la respuesta para su compilación de producción.