elastic / elastic/elastic-package
System tests: Support datastream level assertions
- Dominant language
- Go
- Stars
- 72
- Forks
- 141
- Avg merge
- 19h 42m
- Merged PRs (30d)
- 55
Description
## Background
With the support of detecting multiple datastreams for a system test in https://github.com/elastic/elastic-package/pull/3373#discussion_r2994804604, multiple data streams can now be detected for when an input supports `dynamic_signal_types` , or is of type `traces`. This means assertions `fields_present`, `hit_count` or `min_count` get applied equally to all discovered streams, which may not be desirable, especially in the case of `fields_present`.
Currently this can be controlled in part by using the `signal_types` config to declare which signal types you want to scope the test to, but can be complicated by APM enrichment also adding other streams.
This can also help reduce the amount of separate system tests that need to be defined. For example, a system test asserting on a logs stream, and separately another a metrics stream may use the same policy configuration and result in having to spin up the same test environment multiple times.
## Criteria
This issue is to design and implement how to describe assertions scoped to particular data streams in system tests.
An example design from https://github.com/elastic/elastic-package/pull/3373#discussion_r2980958214
```
assert:
datastream_count: 2
```
```
assert:
fields_present_per_datastream:
metrics-sqlserverreceiver.otel-*:
- field1
- field2
logs-sqlserverreceiver.otel-*:
- field3
- field4
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Review the system-test assertion configuration and the linked PR #3373 discussions first, then compare the existing fields_present, hit_count, and min_count behavior across discovered datastreams. The work is done when a documented design supports datastream-scoped assertions, including the example datastream_count and per-datastream fields_present forms, with system-test coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100