Métodos de pruebas de API según lo que cada uno detecta en exclusiva
Humo
Detecta: el despliegue está roto.
Costo: minutos. Ejecútalas siempre. Nada más te lo dice tan rápido.
Funcionales
Detecta: comportamiento incorrecto en un endpoint, incluidas las entradas inválidas.
Costo: moderado. La base que todo lo demás da por supuesta.
Integración
Detecta: secuencias que fallan aunque cada paso pase.
Costo: más alto, por el estado. El mayor rendimiento para los errores que ve el usuario.
Regresión no es un método aparte, es una cadencia: ejecutar lo que ya tienes en cada cambio. Contrato detecta desajustes de forma entre servicios que se despliegan por separado. Carga detecta los límites de capacidad. Fuzzing detecta caídas ante entradas malformadas. Comportamiento de seguridad detecta errores de autorización y es mucho más barato de lo que da a entender su fama.
El que la gente clasifica mal
Las pruebas de regresión se enumeran como un método y luego se programan como una actividad, normalmente antes de los lanzamientos. Ahí está el error. La regresión es lo que hacen tus pruebas existentes cuando se ejecutan, y su valor depende casi por completo de la frecuencia con que eso ocurre. Una suite de regresión que se ejecuta una vez al mes es una suite que encuentra los problemas con un mes de retraso.
Cómo elegir sin hacerlos todos
Humo más funcionales en los endpoints críticos. La cobertura útil más barata que existe.
Integración sobre recorridos reales. Donde viven de verdad los errores con los que chocan tus usuarios.
Comprobaciones de autorización. Baratas, y el fallo que más se explota en las APIs reales.
Contrato, solo si los servicios se despliegan de forma independiente.
Carga y fuzzing, cuando lo que está en juego lo justifica. Los dos son reales y los dos son la primera inversión equivocada.
Caja negra frente a caja blanca
Una distinción que importa menos que antes en el trabajo con APIs. Probar a través de la interfaz pública es la opción por defecto correcta, porque es lo que usan tus clientes. El conocimiento de caja blanca sirve para elegir qué probar, no para decidir cómo probarlo.
Dónde confunde la pirámide en el caso de las APIs
La pirámide de pruebas se dibujó para un mundo de unidades e interfaces de usuario, y aplicarla tal cual al trabajo con APIs produce un error habitual.
La pirámide dice que haya pocas pruebas lentas en la cúspide. En las APIs la capa cara no es evidente: una prueba de API es mucho más barata que una prueba de navegador y mucho más cara que una prueba unitaria, y detecta cosas que ninguna de las dos detecta. Los equipos que sitúan las pruebas de API en la punta estrecha de la pirámide acaban teniendo demasiado pocas, y los que las sitúan en la base ancha acaban con una suite lenta llena de aserciones triviales.
Un modelo mental mejor para los servicios es preguntarse qué capa puede siquiera responder a una pregunta determinada. Si un cálculo es correcto es asunto de una prueba unitaria. Si el endpoint lo aplica correctamente es asunto de una prueba de API. Si el usuario llega a él alguna vez es asunto de una capa por encima de las dos. Las proporciones salen entonces de tu producto y no de un diagrama.
Lo que todos los métodos necesitan por debajo
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 se ocupa de ellas con Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, descritos en la documentación de pruebas de API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre el mismo terreno para quien no quiera una instalación local, y toda la superficie de comandos está en el repositorio del CLI.
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 sitúa la comprobación en el repositorio, donde se revisa igual que el resto del build.
Qué métodos cubre TestSprite
Funcionales e integración, más la parte de comportamiento de la seguridad, más la regresión como cadencia y no como actividad. Los planes generados abarcan las categorías funcional, de esquema, de autorización, de manejo de errores y de límites, y se refinan en lenguaje sencillo.
Auto-Authentication mantiene vivas las sesiones durante toda una ejecución, Dynamic Variables traslada valores entre llamadas, 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. Eso es lo que permite que la regresión sea realmente continua en lugar de algo que se programa antes de los lanzamientos, que es el factor que más determina si un método acaba dando valor.
Contrato, carga y fuzzing siguen siendo instrumentos aparte. La ventaja es que los tres métodos de mayor rendimiento dejan de competir con el trabajo de funcionalidades por el tiempo de escritura, de modo que la cobertura existe en lugar de quedarse planificada.
¿Qué método encuentra más errores?
El de integración, en la mayoría de los productos, porque los fallos que ve el usuario suelen surgir entre llamadas y no dentro de una sola.
¿Merecen las pruebas de humo una suite aparte?
Sí. Una comprobación de dos minutos que se ejecuta en cada despliegue cumple una función distinta a la de una suite de veinte minutos, y confundirlas hace que ninguna se ejecute en el momento adecuado.
¿Necesitamos pruebas de fuzzing?
Si que lleguen entradas malformadas a tu servicio tiene consecuencias reales, sí. Para la mayoría de las APIs internas están por debajo de las comprobaciones de autorización y de la cobertura de integración en prioridad.
¿Y las pruebas exploratorias de API?
Realmente valiosas y no automatizables. Hazlas cuando una API es nueva o ha cambiado de forma sustancial, y luego codifica lo que hayas encontrado.
¿Cómo encajan en la pirámide de pruebas?
Solo vagamente. La pirámide se dibujó para unidades y UI. En las APIs, el eje útil es lo que cada comprobación detecta en exclusiva, no la capa a la que pertenece.
Elige según lo que cada método detecta en exclusiva.
A los métodos de pruebas de API conviene ordenarlos por costo frente a rendimiento exclusivo en lugar de memorizarlos. Primero humo y funcionales, integración para los errores de verdad, comprobaciones de autorización porque son baratas, y carga al final.