### Summary
**Sets up the foundations for
https://github.com/elastic/kibana/issues/146000**
- created a new test server under
`x-pack/test/monitoring_api_integration/` that allows loading of
packages at kibana startup
- a test runner utility which is a simple for loop executing the
supplied test twice, one time with `metricbeat` data and a second time
with `package` data
- a utility that allows transformation of package data into metricbeat
data
**Adds API tests for the beats package**
- created a test case for each API exposed
- removed the duplicates from
`x-pack/test/api_integration/apis/monitoring`
-----
_See the included
[README](b55de5c1cc/x-pack/test/monitoring_api_integration/README.md)
for additional details_
This directory defines a custom test server that provides bundled
integrations
packages to the spawned test Kibana. This allows us to install those
packages at
startup, with all their assets (index templates, ingest pipelines..),
without
having to reach a remote package registry.
With the packages and their templates already installed we don't have to
provide
the static mappings in the tests archives. This has the benefit of
reducing our
disk footprint and setup time but more importantly it enables an easy
upgrade path
of the mappings so we can verify no breaking changes were introduced by
bundling
the new versions of the packages.
_Note that while Stack Monitoring currently supports 3 collection modes,
the tests
in this directory only focus on metricbeat and elastic-agent data. Tests
for legacy
data are defined under `x-pack/test/api_integration/apis/monitoring`._
Since an elastic-agent integration spawns the corresponding metricbeat
module under
the hood (ie when an agent policy defines elasticsearch metrics data
streams,
a metricbeat process with the elasticsearch module will be spawned), the
output
documents are _almost_ identical. This means that we can easily
transform documents
from a source (elastic-agent) to another (metricbeat), and have the same
tests run
against both datasets.
Note that we don't have to install anything for the metricbeat data
since the mappings
are already installed by elasticseach at startup, and available at
`.monitoring-<component>-8-mb`
patterns. So we are always running the metricbeat tests against the
latest version of
the mappings.
We could have a similar approach for packages, for example by installing
the latest
packages versions from public EPR before the test suites run, instead of
using pinned
versions. Besides the questionable reliance on remote services for
running tests,
this is also dangerous given that packages are released in a continuous
model.
This means that whenever the test suite would execute against the latest
version
of packages it would be too late, as in already available to users.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
