integration-testing
When to use
Load this skill whenever tasks include:
- authoring or debugging pipeline test fixtures (
.log/.jsoninputs,*-expected.jsonoutput, 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, troubleshootingreferences/system-testing.md— generic system test reference: required layout, config fields, core commands, teardown failures,sample_event.jsonverification, general debuggingreferences/system-testing-cel.md— CEL mock API wiring, 0-hits debugging for CEL, variable-capture patternsreferences/system-testing-tcp-udp.md— TCP/UDP log sender pattern withelastic/stream, signal coordination, port alignmentreferences/system-testing-http-endpoint.md— webhook/HTTP endpoint testing withSTREAM_PROTOCOL=webhook, auth headersreferences/system-testing-logfile.md— Alpine container +SERVICE_LOGS_DIRpattern for logfile/filestream inputsreferences/system-testing-kafka-pubsub.md— Kafka broker + stream producer, Pub/Sub emulator patternsreferences/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 examplesreferences/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 runningelastic-package test system --generateafter pipeline work completes (any testable input). Same dispatch rule as above: orchestrators pass the path, the subagent reads the file itself.