Functional Testing¶
During development of your Ingress solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case.
What is functional testing?
To summarize Wikipedia:
Functional testing is a QA process that sees a "tester" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors.
The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet.
If you've got suggestions and/or functional tests that helped during your development, please let us know!
Reduce Confirmation Bias
It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss.
Basic Functionality Tests¶
The following functionality tests should be applicable to every solution targeting this use case.
Test Case |
Description |
Desired Outcome |
|---|---|---|
| ING-01 | Documentation: Solution should be fully documented | Both online and embedded CRD documentation (when applicable) is provided |
| ING-02 | Error Handling: Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, etc.) | The error will be encountered and a meaningful error message will be presented to the end user and, if applicable, back to Venafi |
| ING-03 | CRUD Lifecycle: Standard logic around creation, modification and deletion | Ingress and its standard behavioral effects should be observable from within TLS Protect For Kubernetes. Ingress is observed as both updated and subsequently deleted. Exceptions to these outcomes must be justified and documented |
| ING-04 | TLS: Support TLS-enabled public routes | TLS-enabled Ingress routes are provisioned and observable from within TLS Protect For Kubernetes. Meanwhile, browser can navigate to workload via HTTPS without security warnings |
| ING-05 | Certificate Renewed: Renew certificate used as a machine identity | Revised expiry date for Ingress machine identity is visible from within TLS Protect For Kubernetes. Ingress reconfiguration is automatically triggered |
Advanced Functionality Tests¶
Depending on the exact functionality of the target solution, the following tests may or may not be applicable.
Test Case |
Description |
Desired Outcome |
|---|---|---|
| ING-101 | OpenID Connect: Integrate with OpenID Connect identity providers | Alongside machine identities security, your solution should also be able to demonstrate support for Authentication and Authorization |