DEV Community

loading...
Cover image for API Testing y no morir en el intento

API Testing y no morir en el intento

Alfred Tejeda
Functional & Automation tester | Testing writer | Automation consultant
Updated on ・3 min read

Cuando nos dicen que debemos de probar una API probablemente lo primero que se nos viene a la mente es: "utilizaré Postman" o en algunos casos SoapUI. Y no está mal; ¿pero realmente sabemos qué debemos probar en una Rest API?.

Hay varios puntos importantes a la hora de crear nuestros casos de pruebas, pero antes de hablar sobre qué debemos probar el punto más importante es entender cuál es el propósito, sabiendo esto podemos determinar nuestros datos de prueba y saber con qué debemos contrastar el resultado: con una base de datos tal vez.

Ahora veamos que debemos probar:

  • Código de respuesta: esto determina el comportamiento que tendrá la aplicación que consume el servicio (frontend) si debe o no mostrar información; redirigir o cualquier otra acción determinada. Hay que tener presente las 5 clases o categorías:
Rango Uso Descripción
1xx Información Se recibe la solicitud y se sigue procesando
2xx Exitoso La solicitud es recibida, comprendida y aceptada con éxito
3xx Redireccionamiento Se deben tomar más medidas para completar la solicitud
4xx Error de cliente La solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error de servidor El servidor no cumple con una solicitud aparentemente válida

Debemos de asegurarnos que según los datos de entrada que estamos utilizando, estemos recibiendo el código de respuesta que corresponda según la definición del endpoint.

Los códigos más comunes son: 200, 201, 304, 401, 402, 403, 404, 412, 500, 503.

  • Cuerpo de respuesta: si tendríamos que definir un orden de importancia el código de respuesta y cuerpo de respuestas estarían en el mismo puesto, esto determina que información va ser mostrada o utilizada desde el frontend. Esta información generalmente viene dada en formato Json por lo que deberíamos validar el JsonSchema (sobre todo si queremos aplicar contrac testing) y la información que esta trae. A su vez debemos conocer cuales campos o pares (llave - valor) son obligatorios u opcionales y sobre estos obligatorios nuestra prueba sería intentar enviar la petición sin estos valores o enviandoles vacío o null.

  • Métodos admitidos por el endpoint: los métodos más utilizados son GET, POST, PUT y DELETE (Lista completa de métodos), cuando recibimos la información del endpoint que vamos a probar siempre nos indican que método este utiliza, lo que debemos hacer es intentar hacer la misma petición pero con otro método.

  • Cabeceras de petición: las cabeceras de petición o headers permiten enviar información adicional entre el cliente y el servidor. Al igual que el cuerpo de respuesta, debemos validar que cabeceras son obligatorias y realizar la petición sin ellas, con valores errados, vacíos y nulos.

Hasta acá tenemos una base para poder empezar a validar el API, en la segunda entrada de API... sin morir en el intento! Vamos a tomar en cosideración para crear nuestros casos de prueba el top 10 de OWASP y así tener algunas pruebas básicas de seguridad.

Me gusta escribir sobre testing en general, gracias a esto me doy cuenta de lo que me falta por aprender, también me encanta el café, por si deseas regalarme uno :)

Discussion (0)