Formación corporativa en Karate

Los ficheros .feature son la unidad básica de organización de tests en Karate. Este módulo desgrana su estructura: la cabecera Feature, los Scenario individuales, el Background para reusar precondiciones y los Scenario Outline con tablas Examples para casos parametrizados. Se compara con la sintaxis de Cucumber clásico para evitar confusiones cuando llegan perfiles desde proyectos BDD anteriores.

La sección práctica incluye los hooks karate-config.js para configurar variables por entorno (dev, staging, prod), el bloque Background para tokens de autenticación reutilizables y la organización de la suite con @smoke, @regression o @b2b-cliente para filtrar la ejecución en pipelines CI/CD según la fase del despliegue.

Este módulo cubre la API HTTP del framework: las palabras clave url, path, param, request, method, status y response, junto con los verbos get, post, put, patch, delete. Aprendes a construir peticiones con cuerpo JSON (incluyendo placeholders #(variable)), a leer la respuesta y a inspeccionar responseHeaders, responseCookies y responseStatus desde aserciones posteriores.

La parte práctica añade header, cookie, multipart file para subida de ficheros y los patrones habituales de autenticación: Bearer con un JWT obtenido en un Background, login OAuth2 con flujo client_credentials en karate-config.js y reuso del token entre escenarios. Se cierra con buenas prácticas de gestión de entornos por variable y por @tag.

El operador match es el corazón del sistema de aserciones de Karate y reemplaza a las APIs de comparación de Hamcrest, AssertJ o JsonPath habituales en Rest-Assured. Este módulo explica sus variantes principales: match == para igualdad estricta de objetos completos, match contains para subconjuntos, match contains only y match contains any para reglas más laxas y match !contains para verificar ausencia de campos.

La sección avanzada introduce el fuzzy matching mediante marcadores especiales (#string, #number, #boolean, #uuid, #regex[\\d{4}], #? predicate) que validan la forma de un campo sin acoplarse a su valor exacto, fundamental para tests estables frente a IDs autogenerados o timestamps. Se cierra con la integración de karate.match y karate.schema para validar respuestas contra JSON Schema externo y compartir contratos entre equipos de QA y backend.

El testing parametrizado en Karate se hace principalmente con Scenario Outline y tablas Examples, donde cada fila genera una invocación independiente del escenario. Este módulo explica la sintaxis (<variable> en placeholders), el uso del marcador read('classpath:...') para leer JSON, CSV o YAML desde src/test/resources, y los patrones para tablas dinámicas generadas por código.

La pieza avanzada son los keywords call y callonce, que permiten invocar otra feature como subrutina y devolver su response o variables al escenario padre. callonce cachea el resultado por suite y se usa para login compartido o seeding de datos. Cierra con karate.forEach, karate.repeat y la composición de features como bloques reutilizables, enfocada a la creación de librerías compartidas entre proyectos B2B.

Karate incluye un servidor de mocks integrado que permite simular APIs externas sin necesidad de WireMock, MockServer o Postman Mock. Este módulo cubre karate-netty y karate-mock-servlet para arrancar un mock standalone desde un fichero .feature, definir respuestas por path y method, y devolver payloads dinámicos basados en la petición entrante.

La aplicación práctica son los virtual services habituales en arquitecturas de microservicios: simular un servicio de pagos durante los tests de integración, devolver 503 para validar manejo de errores, retrasar respuestas con karate.responseDelay para reproducir latencia o cortar dependencias en CI/CD. Se compara con WireMock y se justifica cuándo elegir cada uno según madurez del equipo y cobertura de protocolo.

karate-gatling permite reutilizar las mismas features escritas para tests funcionales como escenarios de carga, evitando duplicar la lógica HTTP en otra herramienta como JMeter o k6. Este módulo introduce la integración Scala/Gradle, la clase Simulation que invoca features con karateFeature(...) y los modeladores de carga (atOnceUsers, rampUsersPerSec, constantUsersPerSec).

La parte práctica construye una simulación realista con tres fases (warm-up, ramp-up, steady) sobre una API REST y revisa los reportes HTML de Gatling: percentiles p95/p99, throughput, distribución de tiempos y mapeo a requisitos no funcionales típicos de un contrato B2B (SLA de 200 ms en p95). Se cierra con la integración del runner en mvn verify y en GitHub Actions con artefactos publicados.

Este módulo cierra el itinerario integrando la suite Karate en un pipeline CI/CD profesional. Se cubre el runner moderno @Karate.Test del módulo karate-junit6, que reemplaza al antiguo KarateOptions y permite ejecutar features individuales o por carpeta desde clases Java estándar lanzadas por Maven Surefire o Gradle.

La parte de reporting integra cucumber-html-reporter y cluecumber-report-plugin para producir HTML navegable con resultados, capturas y detalles de petición/respuesta, listo para adjuntar en PRs. Cierra con un workflow completo en GitHub Actions: cache de dependencias Maven, ejecución de la suite, publicación de artefactos (HTML + JUnit XML), tags @smoke para PRs y suite completa para main. Se incluyen variantes para GitLab CI y Jenkins Declarative Pipeline.