Los cuatro niveles de las pruebas funcionales de API
1. Estado
¿Devolvió 200?
Detecta caídas del servicio. Pasa tan tranquila ante un resultado vacío donde debería haber un registro.
2. Forma
¿Están los campos esperados, con los tipos esperados?
Detecta desviaciones del esquema. No dice nada sobre si los valores son correctos.
3. Valor
¿El total es realmente la suma? ¿El estado es el que debería producir esta acción?
Donde empiezan a detectarse los defectos reales.
El cuarto es la relación: después de crear un pedido, ¿aparece al consultar el cliente? La mayoría de los errores interesantes ocurren entre dos llamadas, no dentro de una sola, y el nivel cuatro es el único que mira ahí.
Por qué las suites se quedan en el nivel dos
Porque los niveles tres y cuatro exigen saber qué significa correcto, y eso implica que alguien tiene que decidirlo. El estado y la forma se pueden derivar mecánicamente de una especificación. El valor y la relación requieren un juicio sobre el producto.
Eso es realmente más difícil, y ahí está todo el valor. Una suite que nunca expresa una regla de producto está comprobando, de forma muy elaborada, que el servicio está en línea.
El caso negativo que la gente se salta
Para cada endpoint, pregúntate qué debería rechazarse y luego afirma que así ocurre. Valores fuera de rango, campos obligatorios ausentes, un identificador que pertenece a otra persona. Los servicios que devuelven 200 con un objeto de error en el cuerpo son lo bastante comunes como para que una suite que ignore ese patrón informe en verde para siempre.
Lo que una suite necesita por debajo
Cuatro cosas deciden si una suite de API sobrevive a su primer año: las sesiones que caducan, los valores que solo existen en tiempo de ejecución, las llamadas que dependen unas de otras y los registros que nadie limpia. TestSprite las resuelve con Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, descritos en la documentación de pruebas de API.
Resolver bien esto es lo que te permite dedicar tu atención a los niveles tres y cuatro en lugar de a la infraestructura.
Llevar la cobertura más allá de lo superficial
Los planes generados parten de una especificación o de una pasada de descubrimiento e incluyen categorías funcionales, de esquema, de autorización, de manejo de errores y de límites, de modo que los casos negativos existen por defecto en vez de depender de que alguien se acuerde de ellos al final de un sprint.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.
Cómo elegir qué endpoints reciben el nivel cuatro
Las aserciones de relación son las más valiosas y también las más caras, así que no deberían estar en todas partes. El filtro que funciona es preguntarse cuánto costaría una respuesta equivocada.
Todo lo que mueve dinero, cambia permisos o sirve de base para una decisión que toma otra persona recibe el nivel cuatro. Un pedido que existe pero no está vinculado a un cliente, una concesión de permisos que solo se aplicó en un lado, un informe coherente consigo mismo que contradice los registros subyacentes. Esos son los fallos caros y silenciosos.
Los endpoints de informes de solo lectura, las comprobaciones de estado y todo aquello cuya salida una persona revisa de inmediato no lo necesitan. Ser deliberado con esto es lo que mantiene la suite lo bastante rápida como para que la gente la ejecute.
Ejecútala en cada cambio
Dos caminos, y la elección depende en realidad de quién es dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu build ya emite. Añadir un paso de GitHub Actions deja la comprobación en el repositorio, donde se revisa como el resto del build.
Cómo TestSprite te lleva más allá del nivel dos
Los planes generados incluyen los casos negativos por defecto, en las categorías funcional, de esquema, de autorización, de manejo de errores y de límites, que es donde la mayoría de las suites escritas a mano se quedan sin fuerzas. Los refinas en lenguaje sencillo, y ese refinamiento es la vía por la que tu conocimiento del producto entra en la suite.
Los niveles de valor y de relación son los que merecen tu atención, y también los que necesitan a alguien que conozca el producto. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables lleva valores de una llamada a otra, Dependency Chains deriva el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que la ejecución creó. Así, el tiempo que inviertes se va en qué significa correcto y no en la infraestructura.
Lo que obtienes es una suite que hace aserciones sobre los cuerpos de las respuestas y sobre las relaciones entre llamadas, ejecutándose en cada cambio, en lugar de un pipeline en verde que demuestra que el servicio está en línea.
¿Las aserciones sobre el código de estado son inútiles?
No, simplemente son el suelo. Consérvalas y añade al menos una aserción de nivel valor por cada endpoint que importe.
¿Cómo decidimos qué significa correcto?
Pregunta qué promete el producto, no qué hace el código. Si para un endpoint concreto nadie sabe responder, esa ambigüedad ya merece salir a la luz.
¿Todos los endpoints deberían tener los cuatro niveles?
No. Reserva los niveles tres y cuatro para los endpoints en los que un valor equivocado tiene consecuencias. Los endpoints de informes y las comprobaciones de estado no los necesitan.
¿Y las aserciones generadas?
Útiles para los niveles uno y dos, que son mecánicos. Los niveles tres y cuatro se benefician de una revisión, porque ahí es donde entra el conocimiento del producto.
¿Cuántos casos negativos por endpoint?
Uno o dos que importen valen más que diez que enumeren todas las entradas incorrectas posibles. Elige los rechazos que provocaría un cliente real.
El estado y la forma son el suelo, no el trabajo.
Las pruebas funcionales de API tienen cuatro niveles de aserción y la mayoría de las suites se queda en el segundo. Las aserciones de valor y de relación son las que detectan defectos, y el caso negativo es el que la gente se salta.