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

Policy tests

Policy tests (_dev/test/policy/*.yml with a generated .expected sibling) render the agent policy for a set of vars: and snapshot the result. elastic-package test policy --generate records whatever the template renders, including a broken rendering, so a passing policy test does not prove the variables are wired. After generating, confirm that every variable the fixture sets has a visible effect in the .expected: its value appears, or the block it guards is rendered. A variable that is set in the fixture and absent from the output means the template reads a different name than the manifest declares (see manifest-rules.md in the package-spec skill). Fix the name mismatch, do not edit the .expected by hand.

System test input-specific references

In addition to the generic system-testing.md, load the reference file matching your data stream's input type:

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.