¿Cómo encaja la conexión de prueba con una API de terceros en la integración continua?

Question

Escribí una prueba hace un tiempo que prueba una integración que escribí entre mi código y una API de un tercero. La prueba asegura que la integración funciona correctamente y que obtenemos los resultados esperados.

La compilación formal falló hoy porque la prueba recibió un error 500 al intentar conectarse a la API de terceros.

¿Tiene sentido probar una situación como esta?

Answer 1

En mi opinión, las pruebas de integración pueden fallar si el tercero (db, webservice, etc.) no está disponible. Si no desea probar la integración en sí y solo la funcionalidad simple, puede simular el resultado de su API y probar en su contra. En ese escenario, su prueba ya no depende de la disponibilidad de terceros.

En general, marco las pruebas unitarias dependiendo de la disponibilidad de un tercero con un atributo de grupo como "Integración" y los excluyo del proceso de integración continua. En cambio, los dejo correr en una construcción nocturna. Las pruebas de integración generalmente son costosas en el tiempo y whole point of continuous integration is to provide rapid feedback.

Answer 2

No, no es útil que su suite de pruebas falle cuando un servicio externo está caído. Pero desea probar completamente su integración con el servicio. La siguiente estrategia ha funcionado bien para mí:

• aislar el servicio de terceros en un módulo (digamos una clase, pero sin embargo sus modulariza lenguaje está muy bien), que hace tan poco como sea posible, además de encapsular la conexión a el servicio. Escriba métodos en la clase para que sea posible determinar la diferencia entre los errores que son culpa del servicio y los errores que son su culpa. Por ejemplo, asigne excepciones de servicio a una superclase común.

• pruebas de unidad de escritura de la clase de servicio por lo que

  • si se produce un error de servicio hacia abajo, pero pasan las pruebas de registrar el error.

  • si ocurre cualquier otro error, falle como de costumbre.

  Escriba estas pruebas para que se ejecuten contra el servicio directo. Debe haber un pequeño número de estas pruebas, por lo que no deberían crear un problema para el tiempo de ejecución de la suite de pruebas.

• Combina o burla la clase de servicio de todas las demás pruebas, incluidas las de integración. (Por "pruebas de integración" aquí estoy hablando de pruebas que prueban todas las capas de su propio código, no si interactúan con el servicio de terceros).

  Al anular o burlar la clase de servicio de las pruebas de integración, no resida ni se burle de la API pública de la clase de servicio, sino que resida o se burle de algún nivel inferior, tal vez un método interno de la clase de servicio o la biblioteca que usa para conectarse al servicio. Esto evita errores de integración al llamar a la clase de servicio. En las pruebas unitarias, reste o simula la API pública de la clase de servicio como lo haría con cualquier clase.

Como Martin Buberl sugiere, podría ser útil tener una prueba de funcionamiento por separado de las pruebas de integración, donde la clase de servicio no se apagó o burlaban a cabo.Para ser sincero, esto es algo que se ha discutido en múltiples proyectos en los que participé, pero no creo que se haya hecho nunca. Cuando un servicio de terceros falla, siempre lo averiguamos a partir de los errores de producción (informados por la supervisión o la atención al cliente) antes de que nos enteremos por las pruebas.