test: add Kuadrant operator metrics tests#876
Conversation
| metrics = prometheus.get_metrics( | ||
| key="kuadrant_exists", | ||
| labels={"service": "kuadrant-operator-metrics", "namespace": settings["service_protection"]["system_project"]}, | ||
| ) |
There was a problem hiding this comment.
Try to get all relevant metrics only once, from the shared fixture. Then use .filter() on the returned structure to filter metrics you got from a single request to jaeger. Check out the methodology other testsuite tests for metrics follow
There was a problem hiding this comment.
I looked into the existing metrics tests and the .filter() approach isn't unified across the testsuite — some tests use has_label(), others use raw lambdas, and some don't use a shared fixture at all. I can refactor this tests to use the shared fixture + .filter()pattern.
Should I also refactor the other metric tests so that they use a uniform methodology, so that it will be unified throughout the test suite?
There was a problem hiding this comment.
CoreDNS tests will probably have the best usage of the interface for metrics we have in the testsuite currently, I would inspire from them. The main point with filtering on already collected metrics is less API calls done from testsuite.
Should I also refactor the other metric tests so that they use a uniform methodology, so that it will be unified throughout the test suite?
that would be great, doesn't need to be in this PR though 👍
There was a problem hiding this comment.
I've refactored the metrics tests based on the suggested CoreDNS pattern. I will also open a new issue to unify the rest of the metrics tests across the testsuite to follow the same approach, so we do not forget about that.
testsuite/tests/singlecluster/observability/test_kuadrant_operator_health_metrics.py
Outdated
Show resolved
Hide resolved
Signed-off-by: Silvia Tarabova <starabov@redhat.com>
1fd1a4f to
e2181e6
Compare
Description
kuadrant_policies_totalandkuadrant_policies_enforced) across all policy kindstest_observability.pyfor clarityCloses #875
Verification steps
The lifecycle test requires sequential execution (marked
disruptive):