Functional Testing¶
During development of your Issuer 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 |
|---|---|---|
| ISS-01 | Documentation: Solution should be fully documented | Both online and embedded CRD documentation (when applicable) is provided |
| ISS-02 | Error Handling: Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, provider-centric policy violation, etc.) | A meaningful error message will be recorded in the cert-manager logs and will propagate to the TLS Protect For Kubernetes front-end |
| ISS-03 | New Certificate: Provision a new certificate for use as a machine identity | Certificate is delivered back to cert-manager and observably ready for use from within TLS Protect For Kubernetes |
| ISS-04 | Certificate Renewed: Renew certificate for use as a machine identity | Certificate is delivered back to cert-manager and revised expiry date is visible from within TLS Protect For Kubernetes |
| ISS-05 | Approval Status: Without approval from the approver-policy component of TLS Protect For Kubernetes Enterprise, no certificate should be issued | Unapproved certificates will be flagged as such in TLS Protect For Kubernetes |
| ISS-06 | Ingress Integration: Provide seamless integration with Ingress Controllers | Ingresses enlisting the support of your Issuer solution will behave as per native Issuers with regard to machine identities |
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 |
|---|---|---|
| None |