Resolved mismatch stubbings in MultiRequestHttpClientServiceImplTest.java

[ARMS2025]

I analyzed the test doubles (mocks) in the test code of the project. In my analysis of the project, I observed that

In the test testGetSharedClient:

• the getAttribute method for the session object:
  i) during test execution the method is actually called with arguments ["org.springframework.web.util.WebUtils.MUTEX", 1], but is not stubbed, resulting in a mismatch stubbing.

In the test testGetUnsharedClient:

• the getValue method for the preferences object:
  i) is stubbed in the setUp method with arguments [MultiRequestHttpClientServiceImpl.HTTP_CLIENT_CONNECTION_TIMEOUT, String.valueOf(MultiRequestHttpClientServiceImpl.DEFAULT_HTTP_CLIENT_CONNECTION_TIMEOUT)]
  ii) during test execution the method is actually called with arguments ["sharedSessionKey", null], resulting in a mismatch stubbing
• the getAttribute method for the session object:
  i) during test execution the method is actually called with arguments ["org.springframework.web.util.WebUtils.MUTEX", 1], but is not stubbed, resulting in a mismatch stubbing.

In the test testCreateUnsharedClient:

• the getValue method for the preferences object:
  i) during test execution the method is actually called with arguments ["sharedSessionKey", null], but is not stubbed, resulting in a mismatch stubbing.

In general, a mismatched stubbing occurs when a method is stubbed with specific arguments in a test but later invoked with different arguments in the code. Mockito recommends addressing this type of issue (https://www.javadoc.io/doc/org.mockito/mockito-core/latest/org.mockito/org/mockito/exceptions/misusing/PotentialStubbingProblem.html).

I propose a solution below to resolve the mismatch stubbing. Happy to modify the pull request based on your feedback.

[bjagg]

Thanks for the contribution. These auto-generated strict-stubbing cleanups target Mockito.STRICT_STUBS-mode issues, but this portlet's tests pass today on Mockito 4.11 with @RunWith(MockitoJUnitRunner.class). The changes here add when(...).thenReturn(null) stubs for calls that already return null by default (or move stubs into the tests that use them — a valid style fix but not a correctness fix).

We're also currently blocking a Mockito 5 migration at the fleet level because Mockito 5's inline MockMaker has a byte-buddy classpath clash with the Javassist 1.12 pulled via Hibernate (NoSuchFieldError: JAVA_V21). When we eventually reconcile byte-buddy at the parent POM and move to Mockito 5, strict-stubbing cleanups like this one will become relevant — we'd prefer to do them as part of that coordinated migration rather than piecemeal now.

Closing this out for now. If you're interested in contributing the same set of fixes as part of the eventual Mockito 5 migration PR, that'd be welcome.