You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

JUnit与Mockito测试报错:参数不匹配,求排查AccountController测试问题

Troubleshooting Mockito "Argument(s) are different!" Error in Your AccountController Test

Hey there! That Mockito argument mismatch error is super common when testing Spring controllers—let’s break down what’s probably going wrong and how to fix it.

First, let’s recap: the error means the arguments your test expects your AccountService to receive don’t exactly match what the AccountController is actually passing to it when the test runs. Here are the most likely culprits and how to check them:

1. Mismatched Request Parameters in Your Test

Looking at your controller code, the btnSearchClick method takes sClientAcctId and a vararg (S...) as parameters. If your test isn’t properly passing these parameters via the MockMvc request, the controller will send null or unexpected values to the service—causing Mockito to throw the mismatch error.

Fix:

Make sure you’re explicitly adding request parameters to your MockMvc call. For example:

mockMvc.perform(get("/api.spacestudy.com/SpaceStudy/Admin/Account/findAccountData")
                .param("sClientAcctId", "your-test-client-id")
                .param("filterParam", "value1", "value2")) // Match your vararg parameters

2. Incorrect Handling of Varargs in Mockito

Mockito can be finicky with vararg parameters (the S... in your controller method). If you’re trying to match exact values for the vararg, Mockito might not recognize them as equal to what the controller sends (since arrays use reference equality by default).

Fix:

Use Mockito’s any() matcher for varargs instead of hardcoding values. For example, if your service method looks like findAccountData(String sClientAcctId, String... filters), set up your mock like this:

when(accService.findAccountData(eq("your-test-client-id"), any(String[].class)))
                .thenReturn(yourMockedTupleList);

The eq() ensures the client ID matches exactly, while any(String[].class) accepts any array of strings for the vararg.

3. Missing @RequestParam Annotations in the Controller

If your controller method parameters don’t have @RequestParam, Spring might not bind the request parameters correctly. This means the controller could receive null values even if you pass them in the test.

Fix:

Double-check your controller method signature—add @RequestParam to each parameter (including the vararg):

@GetMapping("/Account/findAccountData")
public ResponseEntity<List<Tuple>> btnSearchClick(
        @RequestParam String sClientAcctId,
        @RequestParam String... filters) { // Adjust the type to match your "S"
    // Controller logic here
}

4. Typos in Parameter Names

Even a tiny typo between your test’s param() call and the controller’s parameter name will cause a mismatch. For example, if your controller uses sClientAcctId but your test uses clientAcctId, the parameter won’t bind, and the service will get null.

Fix:

Cross-verify the parameter names in your controller, test, and request URL—make sure they’re identical.

Quick Debugging Tip

If you’re still stuck, add a log statement in your controller method to print the actual parameters it receives:

@GetMapping("/Account/findAccountData")
public ResponseEntity<List<Tuple>> btnSearchClick(String sClientAcctId, String... filters) {
    System.out.println("Received sClientAcctId: " + sClientAcctId);
    System.out.println("Received filters: " + Arrays.toString(filters));
    // Rest of the logic
}

Compare these values to what you’re expecting in your Mockito when() call—this will instantly show you where the mismatch is.


内容的提问来源于stack exchange,提问作者SpringUser

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.27 04:09:22