This page provides you with resources/references to write tests to validate various aspects of Managed OpenShift clusters.
Tests can be consumed by osde2e test framework in one of two ways:
- Runs tests outside of osde2e using its test harness runner (recommended)
- Runs tests that reside within osde2e (legacy mode/not recommended)
For any new tests, they should be written in which osde2e consumes them using its test harness runner feature. This applies to all OSD SREP operator tests.
To learn more about the test harness runner of osde2e, refer to the following document.
When writing new tests or enhancing existing tests, every test should strive to comply to the following standards:
- Follow the Kubernetes best practices guide when writing end to end tests.
- Review Ginkgo and Gomega documentation as these are the core test frameworks when writing OSD SREP operator tests.
- Use osde2e-common module as much as possible when writing test cases. This module provides common modules when working with Managed OpenShift which aim to reduce code duplication across tests such as clients for interfacing with OCM, OpenShift, Prometheus and more.
- Use the e2e-framework as much as possible and become familiar with it when interfacing with OpenShift clusters.
- Apply labels "tags" to your test cases allowing for easy classification "grouping" of tests. This is helpful when certain tests would like to be run over the entire test suite.
- Keep test cases focused on their specific scope. Test cases are best to be mapped to a given feature/functionality for the product or OSD SREP operator.
- Ensure both positive/negative cases are covered for your test case.
- Ensure every test case has proper error messages logged with using Gomega matchers. This helps when it comes to troubleshooting/debugging failing tests.
You can find well defined examples of existing tests following the test standards mentioned above below. The examples are showing how tests are written for OSD SREP operator tests:
Additional examples can be found below: