Un mapa de herramientas de testing por aporte exclusivo
Unitaria
Detecta de forma exclusiva: lógica incorrecta, en milisegundos y con la ubicación exacta del fallo.
El feedback más barato que existe. Nada lo sustituye.
API
Detecta de forma exclusiva: comportamiento incorrecto en la frontera del servicio, incluidos casos que ninguna interfaz expone.
Más rápida y más precisa que controlar un navegador.
Extremo a extremo
Detecta de forma exclusiva: que el producto ensamblado falle aunque cada parte funcione.
La más lenta y la única capa que responde a la pregunta del usuario.
Alrededor de ellas hay tres especialistas: contrato para las derivas de estructura entre servicios desplegados de forma independiente, carga para la capacidad, y análisis de seguridad para clases de vulnerabilidades conocidas. Cada uno detecta algo que las tres capas principales no pueden, y ninguno las sustituye.
Dónde suele estar la brecha
La mayoría de los equipos tiene pruebas unitarias y algo de cobertura de extremo a extremo, con poco en la capa intermedia. Está al revés, porque la capa de API detecta la mayoría de los defectos visibles para el usuario a una fracción del costo de la capa que está por encima.
La segunda brecha habitual es que la cobertura va por detrás del volumen de código. Eso no se arregla con otra categoría de herramientas, se arregla con cobertura que no dependa de cuánto alcance a escribir una persona.
La pregunta que vale más que una tabla de funcionalidades
Sea cual sea la capa en la que estés buscando, pregunta cómo se ve un fallo para quien tiene que arreglarlo, y si una ejecución que nunca llegó a sus aserciones se reporta como aprobada. Esas dos cosas predicen el valor de una herramienta mejor que cualquier cosa de su página de comparación.
La herramienta que ya tienes y no usas
Antes de añadir nada, conviene revisar qué hay ya instalado y sin uso, porque la mayoría de las organizaciones tiene más capacidad de testing de la que aprovecha.
Casi siempre hay un framework de pruebas unitarias con un puñado de pruebas de hace dos años. Suele haber una suite de navegador que se ejecuta cada noche y que nadie lee. Con frecuencia hay un escáner que publica un informe en un canal silenciado. Cada una de esas cosas se compró o se configuró por una razón y dejó de usarse por una razón, y vale la pena conocerla antes de volver a gastar dinero en la misma categoría.
La respuesta habitual es que los resultados sobre los que nadie actúa terminan ignorándose, y eso es un problema de proceso, no de herramientas. Una herramienta nueva hereda el mismo proceso y llega al mismo lugar, solo que más tarde y con más gasto.
En qué invertir la próxima hora
El flujo que te daría vergüenza romper, cubierto de extremo a extremo.
La API que hay detrás, cubierta incluyendo los casos negativos.
Lo último que se rompió, convertido en una verificación permanente.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre lo mismo para quien no quiera una instalación local, y el conjunto completo 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 nada cambia en tu repositorio.
GitHub Actions coloca el paso dentro de tu propio flujo de trabajo, configurado desde la terminal.
Dónde se sitúa TestSprite en el mapa
En la capa de API y en la de extremo a extremo, que son las dos donde vive la mayoría de los defectos visibles para el usuario y donde está la brecha habitual. Ejercita el producto en ejecución en lugar de un mock, genera cobertura a partir de tus fuentes y de una pasada de descubrimiento, y refina en lenguaje llano.
Auto-Authentication mantiene las sesiones vivas durante toda una ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deduce el orden de ejecución y Auto-Cleanup elimina exactamente lo que creó la ejecución. Los pasos de navegador son intenciones en lugar de selectores, así que los rediseños no ponen la suite en rojo.
Las pruebas unitarias siguen siendo tuyas y siguen siendo el feedback más barato que tienes. Las pruebas de contrato, las de carga y el análisis de seguridad siguen siendo instrumentos aparte. La ventaja es que la capa intermedia se rellena sin sumar una carga de escritura de pruebas que compita con el trabajo de entregar.
¿Cuántas herramientas de testing deberíamos tener?
Las mínimas que cubran las capas que necesitas. Cada herramienta adicional es una cosa más que configurar, ejecutar e interpretar.
¿Sigue siendo válida la pirámide de pruebas?
La forma es un punto de partida razonable. La versión útil no es una proporción, es preguntarse qué detecta cada capa de forma exclusiva.
¿Deberíamos estandarizar entre equipos?
Para los informes y la integración con CI, sí. Imponer una sola herramienta a todos los equipos suele producir una herramienta que un equipo usa bien y los demás evitan.
¿Cuál es la brecha más común?
Una capa de API escasa. Los equipos saltan de lo unitario a lo de extremo a extremo y se pierden el nivel donde detectar la mayoría de los defectos visibles para el usuario sale más barato.
¿Cómo sabemos si una herramienta se está ganando su lugar?
Por los defectos escapados que detecta y por si alguien lee sus resultados. Una herramienta que nadie lee es una suscripción.
Mapea por aporte exclusivo, no por categoría.
Vale la pena mapear las herramientas de testing según lo que cada capa detecta y ninguna otra puede. La brecha habitual es una capa de API escasa, y la pregunta que vale más que cualquier tabla de funcionalidades es cómo se ve un fallo para quien tiene que arreglarlo.