Las pruebas de API son una parte importante del ciclo de vida del desarrollo de API. Ayuda a detectar cosas como errores de procesamiento de datos, fallas de seguridad importantes y fallas en la funcionalidad de la API. Desafortunadamente, algunos desarrolladores y consumidores de API no le dan a las pruebas de API la seriedad que se merece y terminan cometiendo algunos errores que vale la pena mencionar. De hecho, hay varias técnicas detrás de las pruebas de API, como se explica en esta publicación de blog. en RapidAPI.
En este artículo, vamos a hablar sobre los errores comunes que se cometen al probar las API independientemente de la técnica de prueba empleada.
Entradas errantes
Las entradas erróneas son puntos en el código API que tienen una pieza de referencia, estrangulamiento, función o categoría definida como parte de un conjunto pero que funciona individualmente. En tal situación, la API parece funcionar bien sin problemas ni errores. Sin embargo, se observan errores cuando se prueba el punto final individual. Estos problemas son muy frustrantes ya que la mayoría de las veces, el problema en cuestión es algo simple que funciona bien cuando se llama solo, pero luego falla cuando se llama con otros recursos.
La solución a esto es simplemente hacer muchas pruebas en profundidad. Los problemas pequeños, como los puntos de entrada de datos erróneos, se pueden identificar fácilmente durante las primeras pruebas cuando se prueban puntos finales individuales. Las pruebas tanto en sentido descendente como ascendente ayudarán a identificar áreas con entradas deficientes que podrían afectar el rendimiento general de la API.
Campos inválidos
Hay situaciones en las que una API devuelve datos inesperados o incluso incorrectos. Las aplicaciones siempre tendrán sus problemas, haciendo que los pequeños errores se conviertan en grandes desastres. Por ejemplo, la mayoría de los desarrolladores devuelven HTTP o NULL como respuesta cuando devuelven un objeto URL. Imagine una situación en la que esta respuesta tiene un formato incorrecto, por ejemplo, devuelve HTTP: NULL. Esto hará que muchas aplicaciones, navegadores o incluso dispositivos de terceros lean la respuesta como una URL válida e intenten navegar hasta el recurso.
La solución a esto es asegurarse de probar la validez de un campo con permutaciones. Necesita ser más difícil con su API para que pueda lidiar fácilmente con las fallas a largo plazo. Además, la documentación adecuada es muy importante. Ayuda a los usuarios a saber qué esperar y les facilita la codificación.
Almacenamiento en caché desactualizado
El almacenamiento en caché hace posible que los usuarios accedan al mismo recurso sin tener que agregar más carga al servidor que podría terminar extendiéndolo más allá de sus capacidades. Aunque esta es una buena práctica, una implementación incorrecta es tan mala como ignorarla por completo. Algunos desarrolladores implementan técnicas de almacenamiento en caché deficientes que, la mayoría de las veces, conducen a la coherencia de la caché o al usuario final a obtener un error 404.
La solución a esto es probar la API como si fuera el usuario final. Asegúrese de probar todos los demás puntos finales que tenga. Agregue más entradas, elimine otras e incluso manipúlelas. Si tiene algún problema con alguno de los puntos finales, asegúrese de solucionarlo. Esto asegurará que el usuario final no se enfrente al mismo problema.
Falsos positivos
Una respuesta de 200 cuando se utilizan API significa que todo está funcionando bien. Sin embargo, la mayoría de los desarrolladores ponen el estado predeterminado en 200, lo que significa que incluso la respuesta de un error NULO será 200. Aquí, el desarrollador de la API no ve nada mal. Los sistemas de prueba también están obteniendo la respuesta esperada. También todo parece estar bien para el usuario final, pero no es así. Este es un falso positivo que no permite que el desarrollador vea un error cuando ocurre.
La solución a esto es asegurarse de verificar sus respuestas de error con bastante frecuencia para asegurarse de que se comporten como se espera. Además, asegúrese de haber reservado 200 respuestas solo para respuestas positivas en comparación con su uso como respuesta estándar. Todas las respuestas deben ser concisas, claras y comprensibles.
Finalmente, otros errores comunes para verificar incluyen fallas en la comunicación del equipo, estandarización no estándar, problemas de legibilidad y compatibilidad.
