Pruebas de carga de una API .NET con k6 y GitHub Actions

Pruebas de carga de una API .NET con k6 y GitHub Actions

Pruebas de carga son esenciales para garantizar que una API pueda soportar un gran número de usuarios simultáneos. Esta técnica simula usuarios virtuales y analiza los tiempos de respuesta y errores. En este artículo, utilizaré k6, una herramienta de código abierto de Grafana Labs, para llevar a cabo una prueba de carga a una API REST en .NET 8. El resultado se mostrará en GitHub Pages.

K6 es una excelente opción para realizar pruebas de carga, ya que es fácil de leer y versionar junto con el código, solo requiere un binario y corre sin problema en un runner de CI. Además, permite establecer umbrales (thresholds) para detectar problemas de rendimiento. Si la API no cumple con los estándares, k6 terminará con un error y el pipeline fallará. También genera un dashboard web en HTML con gráficos de la ejecución.

La API utilizada es Banco API, una aplicación Minimal API en .NET 8 que tiene endpoints para operaciones básicas como crear, depositar, retirar y eliminar cuentas bancarias. Los datos están en memoria, lo cual simplifica las pruebas. Para la parte funcional de la API, también se realizan pruebas con Newman, explicado en un artículo de mi colega Victor Carretero.

El script de carga se encuentra en tests/k6/carga.js y define cómo se aumenta la carga y qué se considera aceptable. Los usuarios virtuales repiten un flujo realista que incluye la consulta de cuentas y la realización de operaciones. Cada usuario crea su propia cuenta, deposita 50 y retira 30, y se verifica que el saldo final se mantenga correcto incluso con 20 usuarios operando a la vez.

La automatización del proceso se realiza mediante un flujo en GitHub Actions. En este flujo, se instala k6, se ejecuta la prueba de carga y se exporta el dashboard HTML. El resultado de la prueba se publica en GitHub Pages para que sea accesible públicamente.

Los resultados de la primera ejecución, que duró 1 minuto y 45 segundos, muestran buen rendimiento. El 95% de las peticiones se completaron en menos de 1 ms, lo cual está muy por encima del límite de 500 ms establecido. Además, hubo 0 peticiones fallidas y se cumplieron todos los checks. Estos resultados indican que, en este caso, la API está bien optimizada y los cuellos de botella serían visibles solo con una base de datos real.

Con k6, el rendimiento se puede tratar como un requisito más, implementándose en código y validándose automáticamente en cada cambio.