Cómo hacer pruebas de API externas (blackbox)

14

Suponga que está utilizando las API de un proveedor, ¿cómo asegurarse de que su API funcione como se espera?

Mi principal preocupación es que a veces el proveedor empujó los cambios a su código y rompió la API, queremos tener algún tipo de software automático para probarlos continuamente. Como lidiar con esto?

— usuario34401
fuente

Dependiendo del idioma, puede haber herramientas que pueden ayudar (estoy pensando en Pex para bibliotecas / API de C #).

— Steven Evers

10

Respuesta corta: necesita un conjunto de pruebas para una API de proveedor de terceros, por lo que tendrá que desarrollar uno.

No esperes que nadie más lo haga por ti, y no esperes una "bala mágica" para generar automáticamente las pruebas correctas.

Algunas cosas que puedes probar adicionalmente:

pregúntele al proveedor si proporciona una lista de "cambios importantes" para cada nueva versión
pregúnteles cómo se preocupan por la compatibilidad API / infórmeles que esta es una característica importante para usted
compruebe si la API proporciona ganchos de prueba específicos, resultados de registro o algo así para las piezas que tampoco se pudieron probar fácilmente
envuelva llamadas API importantes con su propio código de registro, escribiendo entradas y resultados relacionados de la API en un archivo de registro, esto facilitará la depuración de cosas si sucede algo inesperado
agregue aserciones a las llamadas de la API para verificar las condiciones previas y posteriores, por lo que si una nueva versión de la API muestra un comportamiento inesperado dentro de su aplicación, recibirá un mensaje de error temprano

Si estas cosas funcionan o no depende de quién es su proveedor y qué tipo de API tiene en mente. Una API que produce algunos resultados inspeccionables como archivos es mucho más fácil de probar que una API que controla algún dispositivo físico donde debe observar el comportamiento de la cosa para decidir si la llamada API fue exitosa o no.

— Doc Brown
fuente

Estoy totalmente de acuerdo, pero me parece que el interlocutor no tiene experiencia con las unidades de prueba y no conoce el esquema de trabajo con ellas. Quiero decir: encontrar puntos críticos, escribir unidades de prueba, ejecutar todas las pruebas, depurar, durante la depuración encontrar nuevos puntos críticos, escribir nuevas unidades, repetir los últimos 4 pasos después de cada cambio de API.

— Gangnus

@Gangnus: En mi humilde opinión, el OP no nos contó nada sobre sus experiencias anteriores con las pruebas unitarias. Si tiene problemas con eso, estoy seguro de que sabe hacer una pregunta más específica. Además, el tema aquí no es "pruebas unitarias", sino "pruebas de integración automatizadas". Esos requieren típicamente un esquema diferente que, por ejemplo, pruebas unitarias en una forma de estilo TDD.

— Doc Brown

Sí, no había dicho eso. Pero si pregunta "cómo asegurarse de que su API funcione como se espera", sin mencionar las pruebas, "me parece", que no las conoce. En cuanto a las pruebas de integración automatizadas, él no las conoce ni siquiera con mayor probabilidad, mencionó simplemente "algún tipo de software automático". Estás esperando de la gente los mismos conocimientos que los tuyos, pero en estos temas el 99% de los programadores (incluyéndome a mí) saben mucho menos. y 90% mucho, mucho, mucho menos.

— Gangnus

0

Basado en la redacción del póster, es más que solo probar, en mi opinión. Después de escribir su prueba de unidad para la API y asegurarse de que todo funciona como se esperaba, debe supervisar las API de terceros para detectar problemas antes de que lo hagan los usuarios. Ese es el riesgo real con las API de terceros: no es su código y no tiene control sobre la cantidad de pruebas que se realizaron en la API o cuándo / si cambia.

(Descargo de responsabilidad: nombres de productos utilizados aquí) Si usa soapUI para escribir sus pruebas de API, esas pruebas pueden reutilizarse en AlertSite como un monitor operativo para asegurarse de que la API siga funcionando como se esperaba. Si no pasa la prueba, puede recibir una alerta antes de que sus usuarios lo llamen y quejarse de que su aplicación no funciona.

— Lorinda Brandon
fuente

0

Implemente pruebas de aprendizaje para su área de interés (características que planea usar). Las pruebas de aprendizaje son pruebas de integración escritas por el desarrollador contra el contrato público de la API. Las pruebas no deben escribirse contra los detalles de implementación internos, incluso si el código fuente de la API está disponible. Este tipo de pruebas de aprendizaje tiene dos propósitos:

Mejora dramáticamente su comprensión de la API de terceros.
Las pruebas ayudan a verificar si la nueva versión reclamada es realmente compatible con versiones anteriores o no.

— Anand Patel
fuente

0

Hay 2 enfoques para este problema ...

su aplicación está en producción con tráfico real de usuarios:

si tiene una aplicación en producción que tiene tráfico en vivo y depende de una API externa, no tiene más remedio que monitorear de cerca y tener buenos umbrales para saber lo más rápido posible cuando la API externa realiza cambios sin notificar.

siempre debes tener en cuenta que:

cambio de api con el tiempo
el vendedor de api puede tener errores
los kits de prueba de los proveedores de API pueden tener errores o no cubrir completamente toda la funcionalidad de la API de producción

su aplicación es una instalación y tiene versiones / lanzamientos planificados:

en este caso, tiene un período de gracia para fallar ... el usuario en vivo no se ve afectado inmediatamente por los cambios externos de la API.

En mi opinión, esta es una tarea más fácil. escriba una prueba (prueba completa de extremo a extremo) que realice transacciones reales / http / solicitudes a su aplicación que invoque la API externa y verifique que no haya fallas. sin kits de prueba sin simulacros de transacción real.

Una vez realizada esta tarea, puede elegir ejecutarla cada 24 horas, 1 minuto, etc.

buenas practicas:

automatizar todo
tener una persona con la que pueda contactar rápidamente del proveedor de la API externa
no confíes ciegamente en que el vendedor prueba todo
falla rápidamente: si su servicio depende en gran medida de la API externa, no permita que su servicio se bloquee. falla rápidamente y devuelve mensajes de error adecuados

herramientas:

aplicación en vivo de monitoreo: nueva reliquia hiperica
pruebas de API: apimetrics RunScope Soapui

— Nimrod007
fuente