El API Testing es necesario para asegurar la calidad de las entregas de nuestros proyectos y para verificar que cumplimos los requisitos. Por ello, hoy veremos cómo probar nuestras APIs.
Comprobar el alcance de nuestra definición
Hoy os traemos la cuarta y penúltima entrega de la serie de blog basada en la formación API Owner Fundamentals que recibieron los miembros de nuestros equipos este año por parte de la Fundación APIAddicts de la que, un año más somos gold partners.
El objetivo del blog de hoy es simplificar lo que se conoce como API Testing, y para ello hablaremos sobre los tipos de pruebas, metodologías de trabajo, y alcance de las pruebas en un proyecto.
Metodologías API Testing
Conoce 3 metodologías clave y sus principales beneficios
BDD
Behavior-Driven Development (BDD) es un proceso de desarrollo software. Busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario, para terminar definiendo criterios de aceptación para esas historias de usuario, haciéndolo en términos de escenarios.
La idea es tener unificado los roles entre desarrolladores, QA y negocio, por lo que se definió un lenguaje común, Gherkin.
Beneficios de esta metodología: colaboración, visibilidad, cumple con las necesidades del usuario y costes.
TDD
Consiste en definir primero las pruebas, después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito.
En cuanto a sus beneficios sobre el código, nos encontramos con mayor robustez, seguridad, mantenibilidad y velocidad.
DDD
Se basa en el Dominio como finalidad para el desarrollo de software. El dominio es una abstracción de la realidad, por lo que el modelo debe ser lo más realista posible. Esta metodología sigue un proceso iterativo-incremental, con reuniones entre los miembros del equipo implicado.
Hablando de sus beneficios, acerca el software al cliente, simplifica el código, divide la lógica de negocio por contextos, es mantenible y se enfoca en el desarrollo.
¿Qué probar?
La realización de pruebas nos permite evaluar y medir cómo de bueno es nuestro software. Un software es tan bueno como consiga adecuarse a la demanda del cliente, y las pruebas nos van a ayudar a reflejar si estamos lejos o cerca de ese objetivo.
Estas pruebas, además, sirven para detectar errores en el funcionamiento y remediarlos, o prevenir situaciones que nuestro sistema no puede controlar. Con esto en mente, está claro el beneficio que aportan, pero, ¿Qué deberíamos probar y qué no?
El primer paso es definir el alcance de las pruebas. Esto es especificar las funcionalidades del producto que se van a probar, y para ello se hará un análisis de la prioridad de la funcionalidad, y la profundidad de sus pruebas.
El segundo paso es definir el tipo de pruebas que serán necesarias. Aquí hablaremos de pruebas funcionales, regresión, rendimiento… Podemos distinguir dos conceptos de pruebas:
Orientadas a aspectos funcionales
Orientadas a aspectos funcionales. Comprueban si la aplicación cumple con sus especificaciones.
Orientadas a aspectos no funcionales
Se abordan características del producto muy importantes, como el rendimiento, la usabilidad del sistema o la seguridad.
Pruebas Funcionales
1. Unitarios
Estas pruebas deben ser rápidas, reutilizables y concretas. La idea es que cada prueba compruebe una lógica concreta del proceso, abstrayéndose de posibles dependencias entre componentes (para ello se utilizan mocks). Por ejemplo, en caso de que tengamos que recurrir a una consulta sql para hacer un tratamiento posterior del resultado, haríamos uso de un mock para esta consulta, y nos centraremos en validar el proceso posterior, sin la lógica de la consulta. No quiere decir que no se pruebe, si no que es una prueba independiente.
Para probar el funcionamiento de esta consulta, tendremos que tener unos datos de prueba, que puedan dar un resultado esperado con esa consulta. Un test unitario debe ser lo más concreto posible, para aislar la lógica de la mejor manera posible. Son los más numerosos dentro del proyecto, y será el principal indicador de cobertura de código.
2. Integración
Tras tener el proceso controlado con pruebas unitarias, hay que comprobar si los diferentes componentes se comunican y funcionan entre ellos. Un caso puede ser el flujo de antes, la obtención de los datos y el procesamiento de después, y comprobar que funciona bien, o la creación de peticiones para ver si el backend está dejando los servicios disponibles.
3. End-to-End
Son las más costosas, prueban todo el proceso, de inicio a fin. Simulan el comportamiento de un usuario del sistema. Verifican que el flujo del proceso funciona como se espera.
4. Contrato
Relacionadas con las historias de usuario, se define el comportamiento de la aplicación. Un test funcional puede ser a su vez unitario, de integración o end-to-end, dependiendo de la historia de usuario. Relacionado con este tipo de pruebas se enfoca la metodología BDD, con herramientas como Cucumber o Serenity.
5. Regresión
Su finalidad es descubrir si haber hecho un cambio en el programa ha podido generar alguna diferencia respecto a funcionalidad de comportamientos ya definidos y entregados. Orientado sobre todo a control de versiones.
Pruebas No Funcionales
Están relacionadas con aspectos del producto, pero no con su funcionalidad. Lo más común es hablar de pruebas de rendimiento, ya que verifican cómo responde el sistema cuando éste se encuentra bajo una alta carga. Su objetivo es encontrar el límite de nuestro sistema, ver si no se liberan los recursos correctamente, y validar el comportamiento de la aplicación frente a un determinado número de usuarios. Algunos ejemplos son:
Pruebas de APIs
En nuestro caso particular, hablamos de cómo podemos probar la API final. Una API contiene peticiones a consumir por el usuario, por lo que, para probarla, tendremos que hacer estas mismas peticiones y probar las distintas respuestas.
Tenemos que tener en consideración tres aspectos:
1. Métodos
Operación a realizar (GET/POST…). Asegurarnos de que estamos ofreciendo solamente la funcionalidad definida.
2. Parámetros
Se valida la entrada y la salida en cuanto a formato. Se comprueban los headers de la petición, los path params, y los query param.
- Consume -> content-type
- Produce -> Accept
3. Respuestas
Deben coincidir con lo definido en el swagger, se comprobará los códigos de respuesta. Los más comunes son:
- Status OK -> 2XX
- Seguridad -> 401/403
- Status KO ->400/404
Conclusiones
Es importante tener definido un buen plan de pruebas, ya que es el respaldo que vamos a encontrarnos cuando queramos justificar el comportamiento definido por el cliente, y, además, nos permite comprobar si el alcance de la definición va acorde a lo que se ha definido.
Blog realizado por Sergio Pérez
¡Habla con nuestros expertos!
