IM

implement-karate-tests

Automates the generation of executable Karate test scenarios from API documentation and definitions.

Install

mkdir -p .claude/skills/implement-karate-tests && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15383" && unzip -o skill.zip -d .claude/skills/implement-karate-tests && rm skill.zip

Installs to .claude/skills/implement-karate-tests

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Genera archivos .feature ejecutables con Karate Framework desde cualquier fuente de API (URL de docs, Swagger/OpenAPI, definición manual, Postman). Versión standalone independiente de ASDD. Soporta REST, GraphQL, SOAP, UI, performance, mocks y WebSocket.
254 charsno explicit “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Generate executable `.feature` files for Karate Framework
  • Parse API information from various sources (URL, Swagger, Postman)
  • Create independent happy path scenarios
  • Apply `@smoke`, `@regresion`, `@positivo`, `@negativo` tags
  • Organize features by functional group
  • Generate runners per functional group

How it works

The skill generates executable `.feature` files for Karate Framework by parsing API information from various sources and structuring test cases with specific tags and organization.

Inputs & outputs

You give it
API documentation URL, Swagger/OpenAPI file, Postman collection, manual definition
You get back
Executable `.feature` files, `<Dominio>Runner.java` files, `karate-config.js`

When to use implement-karate-tests

  • Generate Karate tests from Swagger/OpenAPI
  • Create automated API test scenarios
  • Write performance and mock tests
  • Integrate API documentation into test suites

About this skill

Implement Karate Tests (Standalone)

Genera archivos .feature ejecutables por grupo funcional desde cualquier fuente de información de API. No requiere ASDD, specs ni Gherkin previo.

⚠️ PASO 0: Verificación previa — OBLIGATORIO

Antes de generar ningún .feature, verifica SIEMPRE:

1. ¿Existe pom.xml en la raíz?
   NO → EJECUTA /setup-karate AHORA
        Luego continúa con el Paso 1
   
2. ¿Existe src/test/java/KarateRunnerTest.java?
   NO → El setup anterior falló. Verifica errores y reintenta.
   
3. ¿Existe src/test/java/karate-config.js?
   NO → El setup anterior incompleto. Reintenta /setup-karate.

4. ¿Existe src/test/java/logback-test.xml?
   NO → El setup anterior incompleto. Reintenta /setup-karate.

Si algo falta, DETENTE y ejecuta setup antes de continuar.

Definition of Done — verificar al completar

  • Proyecto Karate existe (pom.xml en raíz) — si no, ejecutar /setup-karate primero
  • Todos los endpoints descubiertos tienen al menos un Scenario happy path
  • Cada Scenario es independiente (no depende de otro Scenario)
  • No hay URLs, tokens ni credenciales hardcodeadas
  • Tags @smoke, @regresion, @positivo, @negativo aplicados correctamente
  • Datos externos en archivos .json separados (para requests complejos)
  • karate-config.js actualizado con la baseUrl correcta
  • Se generaron runners por grupo: <Dominio>Runner.java en cada carpeta de grupo
  • Se mantiene KarateRunner.java global para ejecutar todo

Lógica de resolución de input

¿Qué proporcionó el usuario?
├─ URL de documentación → hacer fetch, parsear HTML, extraer endpoints
├─ Archivo Swagger/OpenAPI (.json/.yaml) → parsear contrato, extraer endpoints + schemas
├─ Archivo local (.md/.json/.txt) → leer y parsear, extraer endpoints
├─ Definición manual en chat → estructurar la información del usuario
├─ Colección Postman (.json) → parsear colección, extraer requests
└─ Nada (sin fuente explícita) → buscar archivo por defecto:
         ├─ ¿Existe karate-tests.md en la raíz? → leer y parsear
         ├─ ¿Existe api-definition.md en la raíz? → leer y parsear
         └─ No existe ninguno → preguntar al usuario qué API quiere testear

Archivo de definición por defecto: karate-tests.md

Cuando el usuario no especifica fuente, el agente busca karate-tests.md en la raíz del proyecto. Este archivo usa un formato markdown flexible que el agente parsea automáticamente.

Formato mínimo

Cada caso de test se define como un bloque ## con campos clave-valor. El agente reconoce los siguientes campos (case-insensitive, orden libre):

CampoObligatorioDescripción
Status / estadoNoEstado del caso: NOT_IMPLEMENTED, IMPLEMENTED (default: NOT_IMPLEMENTED)
título / titleNombre descriptivo del caso
API URL / url / endpointURL completa o path relativo
Request Method / methodGET, POST, PUT, DELETE, PATCH
Response Code / statusCódigo HTTP esperado
Response JSON / responseNoDescripción o estructura de la respuesta
Request Body / bodyNoJSON del body (para POST/PUT/PATCH)
HeadersNoHeaders adicionales requeridos
Params / Query ParamsNoParámetros de query string
Auth / AuthorizationNoTipo de autenticación requerida
Notas / notesNoInformación adicional para el agente
StatusNoEstado de implementación: NOT_IMPLEMENTED, IMPLEMENTED

Ejemplo de karate-tests.md

# Tests de API — Automation Exercise

Base URL: https://automationexercise.com

## Caso 1
título: API 1 - GET All Products List
API URL: https://automationexercise.com/api/productsList
Request Method: GET
Response Code: 200
Response JSON: All products list
Status: NOT_IMPLEMENTED

## Caso 2
título: API 2 - POST To All Products List
API URL: https://automationexercise.com/api/productsList
Request Method: POST
Response Code: 200
Response JSON: All products list (should fail without search params)
Status: IMPLEMENTED

## Caso 3
título: API 5 - POST To Search Product
API URL: https://automationexercise.com/api/searchProduct
Request Method: POST
Request Body: { "search_product": "top" }
Response Code: 200
Response JSON: Searched products list
Status: NOT_IMPLEMENTED

## Caso 4
título: API 11 - POST Create Account
API URL: https://automationexercise.com/api/createAccount
Request Method: POST
Request Body:
  {
    "name": "Test User",
    "email": "[email protected]",
    "password": "pass123",
    "firstname": "Test",
    "lastname": "User",
    "address": "123 Street",
    "country": "USA",
    "state": "CA",
    "city": "LA",
    "zipcode": "90001",
    "mobile_number": "1234567890"
  }
Response Code: 200
Response JSON: User created
Auth: No
Status: NOT_IMPLEMENTED

Reglas de parsing

  1. # Título principal (h1): nombre del grupo / suite. Si incluye Base URL: en esta sección, se usa como baseUrl.
  2. ## Caso N (h2): cada h2 delimita un caso de test independiente.
  3. Campos clave-valor: el agente busca campo: seguido del valor. Acepta variantes en español e inglés.
  4. Request Body multilínea: si el body ocupa varias líneas, se parsea como JSON hasta el siguiente campo o bloque ##.
  5. Campos no reconocidos: se ignoran sin error (el formato es extensible).
  6. Base URL: si se define en el h1, el agente actualiza karate-config.js. Si cada caso tiene URL completa, el agente extrae el dominio común como baseUrl.

Agrupación automática

El agente agrupa los casos por dominio funcional basándose en:

  • Prefijo de path común: /api/productsList, /api/searchProduct → grupo "products"
  • Palabras clave en el título: "Products", "Account", "Brand" → un grupo por cada una
  • Si no puede agrupar, crea un solo feature con todos los casos

Campo STATUS

El agente respeta el estado de cada caso para decidir si implementarlo:

EstadoComportamiento
NOT_IMPLEMENTEDSe implementa por defecto
IMPLEMENTEDSe omite por defecto (no se sobrescribe)

Lógica de decisión

FOR cada caso en karate-tests.md:
  READ status = case.STATUS (default: NOT_IMPLEMENTED)
  
  IF status == IMPLEMENTED:
    SKIP - No generar, no sobrescribir
  ELSE:
    GENERATE .feature normalmente
    UPDATE karate-tests.md: Status = IMPLEMENTED

Flags de control

FlagPropósitoEjemplo
--case <número>Implementar solo un caso--case 1
--status ALLImplementar todos sin importar estado--status ALL
--forceSobrescribir casos IMPLEMENTED--force
--skip-updateNo actualizar el STATUS en karate-tests.md--skip-update

Ejemplos de uso

Implementar solo NOT_IMPLEMENTED (default):

Implementa los tests del karate-tests.md

Implementar caso específico:

Implementa el caso 1 del karate-tests.md

Implementar todos sin importar estado:

Implementa los tests del karate-tests.md --status ALL

Sobrescribir un caso ya implementado:

Implementa el caso 2 --force

Mostrar estado actual:

Muestra el status de los tests del karate-tests.md

Proceso de generación

Paso 1: Descubrir endpoints

Según la fuente, extraer para cada endpoint:

  • URL / path: /api/productsList
  • Método HTTP: GET, POST, PUT, DELETE, PATCH
  • Request body (si aplica): campos, tipos, required/optional
  • Response esperada: status code, estructura JSON
  • Headers requeridos: autenticación, content-type
  • Parámetros: path params, query params

Parsing de URL de documentación

Cuando la fuente es una URL:

  1. Hacer fetch de la URL
  2. Parsear el HTML para extraer tablas o listas de APIs
  3. Buscar patrones como:
    • "API URL:", "Request Method:", "Response Code:"
    • Tablas con columnas de endpoint, método, descripción
    • Bloques de código con curl o request examples
  4. Si la página no es parseable, pedir al usuario que copie la información

Parsing de Swagger/OpenAPI

Cuando la fuente es un archivo OpenAPI:

  1. Leer el archivo .json o .yaml
  2. Extraer paths con sus operaciones
  3. Extraer schemas / definitions para request/response bodies
  4. Extraer securityDefinitions para autenticación
  5. Mapear tags a grupos funcionales

Paso 2: Agrupar por dominio

Organizar los endpoints en grupos funcionales:

  • Por recurso: todos los endpoints de /api/products* → grupo "products"
  • Por tag (si Swagger): usar los tags definidos
  • Por prefijo de path: /users/*, /orders/*, etc.

Paso 3: Generar .feature por grupo

Para cada grupo funcional:

Archivo principal <dominio>.feature (happy path)

@smoke @<dominio>
Feature: API de <Dominio>
  Tests de integración para los endpoints de <dominio>

Background:
  * url baseUrl

@positivo
Scenario: <Descripción del endpoint> - Happy path
  Given path '<endpoint>'
  When method <metodo>
  Then status <code>
  And match response == '#notnull'

Paso 4: Detectar y generar tipos especiales

API REST (por defecto)

@positivo @smoke
Scenario: Obtener todos los <recursos>
  Given path '<endpoint>'
  When method get
  Then status 200
  And match response == '#notnull'

GraphQL (si se detecta)

Scenario: Query GraphQL - <operación>
  Given url baseUrl + '/graphql'
  And request { query: '#(query)' }
  When method post
  Then status 200
  And match response.data == '#notnull'
  And match response.errors == '#notpresent'

SOAP (si se detecta)

Scenario: Llamada SOAP - <operación>
  Given url baseUrl + '/ws'
  And request read('data/soap-request.xml')
  And header Content-Type = 'text/xml'
  When method post
  Then status 200
  And match /Envelope/Body/Response/Status == 'OK'

UI (si se solicita con --type ui)

Scenario: Flujo E2E - <descripción>
  Given dr

---

*Content truncated.*

When not to use it

  • When `pom.xml` is not present in the root
  • When `src/test/java/KarateRunnerTest.java` is missing
  • When not using Karate Framework for API testing

Limitations

  • Only create files in `src/test/java/`
  • No hardcoded URLs
  • Each Scenario must be independent

How it compares

This skill automates the creation of Karate test files from diverse API sources, including default file parsing and structured output, which is more efficient than manually writing Gherkin syntax.

Compared to similar skills

implement-karate-tests side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
implement-karate-tests (this skill)04moReviewIntermediate
swapper-integration65moCautionIntermediate
run-api-e2e-tests76moReviewBeginner
langfuse-ci-integration229dReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

swapper-integration

shapeshift

Integrate new DEX aggregators, swappers, or bridge protocols (like Bebop, Portals, Jupiter, 0x, 1inch, etc.) into ShapeShift Web. Activates when user wants to add, integrate, or implement support for a new swapper. Guides through research, implementation, and testing following established patterns.

696

run-api-e2e-tests

novuhq

Run e2e tests for the API service. Use when the user wants to run API E2E tests.

711

langfuse-ci-integration

jeremylongshore

Configure Langfuse CI/CD integration with GitHub Actions and automated testing. Use when setting up automated testing, configuring CI pipelines, or integrating Langfuse tests into your build process. Trigger with phrases like "langfuse CI", "langfuse GitHub Actions", "langfuse automated tests", "CI langfuse", "langfuse pipeline".

212

api-test-generator

mikopbx

Генерация полных Python pytest тестов для REST API эндпоинтов с валидацией схемы. Использовать при создании тестов для новых эндпоинтов, добавлении покрытия для CRUD операций или валидации соответствия API с OpenAPI схемами.

16

http-generate

spring-ai-alibaba

Generates HTTP request examples for Spring Boot Web interfaces according to task specification and saves them as .http files in module-generate.md directories

16

openapi-analyzer

mikopbx

Извлечение и анализ OpenAPI 3.1.0 спецификации из MikoPBX для валидации эндпоинтов. Использовать при проверке соответствия API, генерации тестов, проверке схем эндпоинтов или интеграции с навыками endpoint-validator и api-test-generator.

25

Search skills

Search the agent skills registry