You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we assert (with upjet) whether a managed resource acquires the UpToDate status condition and whether it can successfully be deleted as unit tests. We are also planning to add new integration tests using compositions. However, it looks like there's still room for increasing test coverage with further unit tests, in addition to asserting the UpToDate status condition.
How could Official Providers help solve your problem?
We could add further test assertions at the unit level:
For certain resource, we could assert whether a connection secret is properly populated and whether it contains the expected data, e.g., certain managed K8s resources should be publishing kubeconfigs in their connection secrets or managed RDBMS resources should be publishing hostnames and credentials necessary for connections.
We could be asserting whether the external resource is behaving as expected, e.g., whether we can connect to it using the populated connection info
We could be asserting whether the managed resource responds to updates as expected (I think this was already discussed as update tests in a relevant design doc) but this is also a unit test for the managed resource
Although we indirectly assert certain configuration such as external names or late initialization (but only failures), for certain resources, we may want to have direct assertions (for regression testing purposes, etc.)
...
We may consider extending our test execution engine (currently uptest) to support running an extensible set of unit tests that are specific to the unit, i.e., we should not assume that all units have the same set of unit tests.
The text was updated successfully, but these errors were encountered:
What problem are you facing?
Currently, we assert (with upjet) whether a managed resource acquires the
UpToDate
status condition and whether it can successfully be deleted as unit tests. We are also planning to add new integration tests using compositions. However, it looks like there's still room for increasing test coverage with further unit tests, in addition to asserting theUpToDate
status condition.How could Official Providers help solve your problem?
We could add further test assertions at the unit level:
We may consider extending our test execution engine (currently uptest) to support running an extensible set of unit tests that are specific to the unit, i.e., we should not assume that all units have the same set of unit tests.
The text was updated successfully, but these errors were encountered: