Issues with mocking command chain types in tests

[vsirohi]

Title: Issues with mocking command chain types in tests

Description

When trying to mock the Helm command chain in unit tests, we're encountering issues with type definitions that make it difficult to properly mock the fluent API. This affects the ability to write comprehensive unit tests for code that uses the helm-java library.

Current Setup

• helm-java version: 0.0.15
• Testing framework: JUnit 5 with Mockito
• Java version: 17

Problem

The current type system makes it challenging to mock the command chain properly. For example, when trying to mock the repo command chain:

@Mock private RepoCommand repoCommand;
when(helm.repo()).thenReturn(repoCommand);
when(repoCommand.add()).thenReturn(repoCommand);
when(repoCommand.withName(anyString())).thenReturn(repoCommand);
when(repoCommand.withUrl(any(URI.class))).thenReturn(repoCommand);

We get compilation errors like:

• The method withName(String) is undefined for the type RepoCommand
• The method withUrl(any(URI.class)) is undefined for the type RepoCommand
• The method call() is undefined for the type RepoCommand

Similar issues occur with InstallCommand and UninstallCommand.

Expected Behavior

The type system should expose the fluent API methods properly to allow for straightforward mocking in tests. This would enable:

1. Proper type checking during compilation
2. Better IDE support for method chaining
3. More maintainable test code

Current Workaround

We're currently working around this by using minimal mocking:

RepoCommand repoCommand = mock(RepoCommand.class);
when(helm.repo()).thenReturn(repoCommand);

However, this doesn't allow us to properly verify the command chain configuration.

Questions

1. What is the recommended way to mock the command chain in tests?
2. Are there specific types we should be using for the mock objects?
3. Is there documentation available for testing with the library?

Additional Context

We're using this library in a service that manages Helm deployments through Java code. Having proper testing support is crucial for maintaining reliability.

Let me know if you need any additional information or clarification.

[manusa]

Hi @vsirohi

In general, any fluent API is very hard to mock, I've done it before but it's pretty ugly.

For this particular library, I would strongly advise against mocking of any type.
Even if we exposed some of the intermediate types, you'd still need to know the inner wirings of the library to provide tests which would make your tests really brittle and hard to maintain.

Despite not being documented, there are many tools that you can use to provide solid, reliable, maintainable, and fast tests.

If you check the source code of this library you'll see that there is almost complete test coverage and there's not a single mock.

For testing related to Helm (OCI) registries, you can use the RepoOciServer.
You can check an example in this test: HelmPushTest.

For testing related with Kubernetes, you can use TestContainers like in HelmKubernetesTest.
You can also use the testing tools provided by the Fabric8 Kubernetes Client (depending on your use-case): Kube API Test for full Kube API support or Kubernetes Mock Server for simple CRUD operations.

You can check the JKube tests to see test implementation examples: HelmServiceInstallIT

In any case, I'd rather spend efforts improving the test tooling support than exposing the internals for easier mocking.
If you identify a scenario that can't be tested, we can work on that to see how to cover it.