Repository navigation
Can't unit test own usage of InClusterFactory #103
Description
Bug Report
What did you do?
Created a wrapper function in our operator code that finds the name of the associated OLM OperatorCondition and then uses the InClusterFactory API to set the upgradeable condition. Then we started writing tests to test this function.
What did you expect to see?
Tests to pass or fail depending on the correct writing of the wrapper function and calling the correct InClusterFactory and Condition code.
What did you see instead? Under which circumstances?
The error: get operator condition namespace: namespace not found for current environment.
Since the unit tests are using a fake runtime client and running locally, this was to be expected since InClusterFactory.GetNamespacedName() calls utils.GetOperatorNamespace(). However, what was unexpected was in our tests there is no way to override this since:
- utils package is internal so private
- readNamespace is private
- the library's own tests can override since they share the same package as
readNamespace.
Environment
- operator-lib version: 0.9.x
- github.com/operator-framework/operator-lib v0.9.0
Possible Solutions
- make
readNamespacepublic - provide an interface to allow
GetNamespacedNameto be overridden - allow the namespace to be injected into InClusterFactory (since the operator provides the namespace through
request.namespace, it might be a nice alternative?)
Additional context
Add any other context about the problem here.
Activity
[-]Can unit test own usage of InClusterFactory[/-][+]Can't unit test own usage of InClusterFactory[/+]nunnatsa commentedon Feb 22, 2022
Very similar to #50
joelanford commentedon Feb 22, 2022
The purpose of the PR (#58) that introduced the InClusterFactory is that you could substitute that out in your tests and use a separate implementation of
conditions.Factorysuch thatGetNamespacedName()can return whatever you need it to.phantomjinx commentedon Feb 22, 2022
I did try that earlier but found that
conditiontype is also private -> https://github.com/operator-framework/operator-lib/blob/v0.9.x/conditions/factory.go#L49.So am not sure how that would help. My interface would have to return a
NewConditionof typeCondition* but that would then require a re-implementation of Get and Set. Either way it would be a lot of work just to workaround for a unit test.If it would help my code is located here:
joelanford commentedon Feb 22, 2022
Yeah
Conditionis also an interface. Perhaps we need to implement aFactoryandConditionthat are more suitable for use in tests so that operator-lib users aren't all re-inventing the wheel when they need alternates.However, I don't think we want to change anything about the functionality of the
InClusterFactorybecause it is meant to work for in-cluster use cases only. Background here: #50 (comment)fix(ENTESB-18466): Flag operator as non-upgradeable
fix(ENTESB-18466): Flag operator as non-upgradeable
openshift-bot commentedon May 24, 2022
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting
/lifecycle frozen.If this issue is safe to close now please do so with
/close./lifecycle stale
joelanford commentedon May 24, 2022
/lifecycle frozen
We'd be happy to accept a PR that adds
MockFactoryandMockConditionstructs that implement these interfaces so that these can be subbed in during unit tests for fine-grained testing of the OperatorCondition feature.