Extension methods are difficult to use in automated tests.

kubernetes-client / csharp

Officially supported dotnet Kubernetes Client library

Apache License 2.0

1.06k stars 291 forks source link

Extension methods are difficult to use in automated tests. #488

Closed simonvane closed 3 years ago

simonvane commented 3 years ago

I am using CreateNamespacedCustomObjectAsync (which works really well thanks) and other similar methods that are in k8s.KubernetesExtensions rather than the k8s.IKubernetes.

The problem that is giving me is that I can't use mocking frameworks to mock extension methods in my unit tests. This means I have to look at the source to see what the implementation is for the extension methods then mock the internal calls.

It would be a lot easier for me to test if those methods were on the IKubernetes interface.

brendandburns commented 3 years ago

I would be open to adding an IKubernetesExtensions interface that extends IKubernetes.

simonvane commented 3 years ago

Thanks @brendanburns and sorry for the delayed response.

That would help me but it would mean that consumers would need to inject two dependencies if they want to use methods from both IKubernetes and IKubernetesExtensions. There seems to be an artificial distinction there.

Is there any reason why they couldn't be added to IKubernetes instead?
You may have a way around this but static classes cannot implement an interface so I'm wondering how this idea would work?

Thanks.

brendandburns commented 3 years ago

Both IKubernetes and IKubernetesExtensions are generated so its tricky to make modifications. (if you can figure out a way to make it work without changing those two interface's .cs files than it's prob. ok.

stefanloerwald commented 3 years ago

Would be great to have some helper methods to faciliate mocking. Running into NREs in an extension method is not a nice experience.

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

fejta-bot commented 3 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

k8s-ci-robot commented 3 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-client/csharp/issues/488#issuecomment-809689129): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.