Resolve 3 mismatch stubbings PathBasedServletAcceptorTest.java

[ARMS2025]

We are researchers and analyzed the test doubles (mocks) in the test code of the project. In our analysis of the project, we observed that

• In the test extensionMatchOneInN, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.selectors" and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test extensionPropertyNotSet, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions", "sling.servlet.selectors", and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test selectorOneMatchesOne, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test selectorOneFromNInN, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test selectorZeroInN, the getProperty method, which is previously stubbed, is executed with the argument "sling.servlet.extensions" in the assertAccept method, but the specific argument is not stubbed, leading to a mismatch stubbing.

• In the test selectorOneInN, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test selectorPropertyNotSet, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions", "sling.servlet.selectors", and "sling.servlet.methods" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test methodNoMatch, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.selectors" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test methodPropertyNotSet, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.selectors" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test testStringStrictIn, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.selectors" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

• In the test testEmptyExtensionAndSelectorWithEmpty, the getProperty method, which is previously stubbed, is executed with the argument "sling.servlet.methods" in the assertAccept method, but the specific argument is not stubbed, leading to a mismatch stubbing.

• In the test testEmptyExtensionSpecificSelector, the getProperty method, which is previously stubbed, is executed with the argument "sling.servlet.methods" in the assertAccept method, but the specific argument is not stubbed, leading to a mismatch stubbing.

• In the test testEmptySelectorSpecificExtension, the getProperty method, which is previously stubbed, is executed with the argument "sling.servlet.methods" in the assertAccept method, but the specific argument is not stubbed, leading to a mismatch stubbing.

• In the test testEmptyMethodException, the getProperty method, which is previously stubbed, is executed with arguments "sling.servlet.extensions" and "sling.servlet.selectors" in the assertAccept method, but these specific arguments are not stubbed, leading to mismatch stubbings.

In this pull request, we propose a solution to resolve the mismatch stubbing. This solution has the lowest cognitive complexity (https://www.npmjs.com/package/@genese/complexity#7-cognitive-complexity)
compared to alternative solutions. If preferred, we can submit a pull request with alternative solutions.

Mismatched stubbing occurs when a mocked method is stubbed with specific arguments in a test but later invoked with different arguments in the code, potentially causing unexpected behavior. Mockito recommends addressing these issues, (https://www.javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/exceptions/misusing/PotentialStubbingProblem.html).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[joerghoh]

I am a bit unsure about this PR.

Let's ignore all the whitespace changes for now, which inflate the size of the PR with no real reason.

It tries to solve the problem of mismatch stubbing, a (potential?) problem we have in the unittests. It explicitly stubs the "non-provided" keys (with a return value of null), so in that case the code actually getProperty(unstubedKey) returns null instead a null which any non-stubbed value would return.

So I doubt that it's providing a real value, and I suggest to close it.

Any opinion on that? (There 2 other PRs like this available, so I would treat them the same way.)