integration-testing

Use when creating, running, or debugging elastic-package tests — pipeline fixture authoring and expected output, system tests with mock API wiring, and script tests for failure paths and upgrades. Load the reference file for the test type you are working on.

By elastic · 456 installs

npx skills add elastic/integration-skills --skill integration-testing

Source repository · Upstream listing

integration testing When to use Load this skill whenever tasks include: authoring or debugging pipeline test fixtures ( .log / .json inputs, expected.json output, config files) setting up or debugging system tests ( dev/test/system/ , dev/deploy/ , mock APIs, 0 hits failures) writing script tests for failure paths, API error handling, or package upgrades When not to use Do not use this skill as the primary guide for: ingest pipeline processor design and architecture ( ingest pipelines ) CEL program development ( cel programs ) broad elastic package command selection and stack lifecycle ( elastic package cli ) Reference files — load the one that matches your test type Test type Load when Reference file Pipeline tests Writing fixtures, config files, expected output, debugging pipeline test failures references/pipeline testing.md System tests (generic) Always load for any system test work — config fields, commands, teardown, debugging references/system testing.md Script tests txtar failure/error tests, upgrade tests, mock services embedded in txtar references/script testing.md System test input specific references In addition to the generic system testing.md , load the reference file matching your data stream's input type: Input type Reference file cel references/system testing cel.md tcp , udp references/system testing tcp udp.md http endpoint references/system testing http endpoint.md logfile , filestream references/system testing logfile.md kafka , gcp pubsub references/system testing kafka pubsub.md aws s3 , gcs , azure blob storage , azure eventhub references/system testing cloud skip.md When an integration supports multiple input types, load the generic reference plus each applicable input type reference. When working across multiple test types in one task (e.g. creating a new data stream end to end), load all applicable reference files. References references/pipeline testing.md — directory layout, naming conventions, fixture formats, config options, expected output format and review, core workflow, fixture scenario coverage, data anonymization, troubleshooting references/system testing.md — generic system test reference: required layout, config fields, core commands, teardown failures, sample event.json verification, general debugging references/system testing cel.md — CEL mock API wiring, 0 hits debugging for CEL, variable capture patterns references/system testing tcp udp.md — TCP/UDP log sender pattern with elastic/stream , signal coordination, port alignment references/system testing http endpoint.md — webhook/HTTP endpoint testing with STREAM PROTOCOL=webhook , auth headers references/system testing logfile.md — Alpine container + SERVICE LOGS DIR pattern for logfile/filestream inputs references/system testing kafka pubsub.md — Kafka broker + stream producer, Pub/Sub emulator patterns references/system testing cloud skip.md — when and why to skip system tests for cloud storage inputs (aws s3, gcs, azure blob storage, azure eventhub) references/script testing.md — txtar format, env smoke test, system level skeleton, mock service docker compose and config.yml, upgrade test pattern, pitfalls, full o365 examples references/builder setup subagent guidance.md — subagent operating manual for wiring data collection (docker compose, sample logs, agent stream template, system test config, manifest var cleanup) for non CEL data streams. The orchestrator dispatches subagents by passing this file's path in the task prompt; the subagent reads it itself in its own fresh context. Do NOT embed/paste its contents into the task prompt. references/builder system test subagent guidance.md — subagent operating manual for running elastic package test system generate after pipeline work completes (any testable input). Same dispatch rule as above: orchestrators pass the path, the subagent reads the file itself.