Pruebas de API: qué hacer primero, qué después y qué todavía no

Las cinco actividades que hay dentro de las pruebas de API

• Funcional. ¿Hace un endpoint lo correcto, incluso con entradas inválidas? Empieza aquí. Todo lo demás lo da por supuesto.

• Integración. ¿Producen las secuencias el resultado correcto? Donde están en realidad la mayoría de los errores que ve el usuario.

• Contrato. ¿Coinciden dos servicios en la forma de los datos? Valiosa cuando los despliegues son independientes, ciega a la corrección.

Las otras dos son la carga, que responde a la capacidad y necesita un generador dedicado, y el comportamiento de seguridad, que consiste sobre todo en comprobaciones de autorización y va junto a la cobertura funcional, no en un ejercicio trimestral.

El orden en el que conviene abordarlas

1. Funcional, en los endpoints que importan. Incluidos los casos negativos. Todo lo demás se construye sobre esto.

2. Integración, en los recorridos reales de tus usuarios. De tres a cinco pasos cada uno, no doce.

3. Comprobaciones de autorización en todas partes. Baratas, y la autorización a nivel de objeto es el fallo de API que más se explota.

4. Contrato, si los servicios se despliegan de forma independiente. Sáltatelo si despliegas todo junto.

5. Carga, antes de los lanzamientos. En último lugar, porque probar bajo carga un endpoint incorrecto mide a qué velocidad puedes equivocarte.

Los cuatro problemas, elijas la herramienta que elijas

Cuatro cosas deciden si una suite de API sobrevive a su primer año: sesiones que caducan, valores que solo existen en tiempo de ejecución, llamadas que dependen unas de otras y registros que nadie limpia. TestSprite los resuelve como Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, descritos en la documentación de pruebas de API.

Todos los equipos se encuentran con ellos en el mismo orden y la mayoría se los encuentra por sorpresa. Diseñar pensando en ellos es la diferencia entre una suite que dura y otra que acaba en cuarentena.

La aserción que más importa

Haz aserciones sobre el cuerpo, no solo sobre el estado. Un 200 que lleva una lista vacía donde debería haber un registro es un error que una comprobación de estado da por bueno. Este único hábito detecta más defectos reales que cualquier otro cambio por sí solo.

Los primeros diez casos, en concreto

Si la suite está vacía, lo más difícil es decidir por dónde empezar, y una respuesta genérica te hace perder una semana. Esta es una lista que funciona para la mayoría de los productos.

Tres para el objeto principal del que trata tu producto: crearlo, recuperarlo y hacer aserciones sobre sus campos, borrarlo y confirmar que ya no está. Dos para la autorización: la misma consulta sin credenciales y con las credenciales de un segundo usuario. Dos para la entrada: un campo obligatorio que falta y un valor fuera de rango. Dos para la secuencia que te inquieta antes de un lanzamiento, sea cual sea en tu caso. Uno para el endpoint que se rompió la última vez.

Diez casos, el trabajo de una mañana, y cubren los patrones que provocan la mayoría de los incidentes. Lo que debe guiar la ampliación a partir de ahí es lo que falla de verdad, y no un objetivo de cobertura, porque el segundo enfoque produce suites grandes y que no vienen al caso.

Por dónde empezar hoy

Apunta un proyecto a tu servicio, deja que el descubrimiento enumere lo que existe y lee el plan generado antes de ejecutar nada. El plan te dice más sobre tu API que los primeros resultados, y es donde se añade tu conocimiento del producto.

Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.

• La GitHub App es un webhook que configuras en el panel de TestSprite. Escucha el evento de despliegue que tu pipeline ya produce, así que no cambia nada en tu repositorio.

• GitHub Actions coloca el paso dentro de tu propio flujo de trabajo, configurado desde la terminal.

Dónde encaja TestSprite entre las cinco

Funcional, integración y la mitad conductual de la seguridad. Ejercita el servicio en ejecución, genera planes a partir de una pasada de descubrimiento y tu especificación, y cubre los casos negativos que las suites escritas a mano se saltan.

Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables traslada valores de una llamada a otra, Dependency Chains deduce el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que creó la ejecución. Esos cuatro son los que deciden si una suite sobrevive a su primer año, sea cual sea la herramienta, y tenerlos como parte del producto es la diferencia entre ampliar la suite y mantenerla.

Las pruebas de contrato y las de carga siguen siendo instrumentos aparte, y esto funciona junto a ambas. Lo que obtienes es la capa donde viven la mayoría de los defectos que ve el usuario, cubierta sin un framework propio y ejecutándose en cada pull request.