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:

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 :)