Question

我曾经像其他任何普通的Java类一样对控制器类进行单元测试。我的意思是不使用Spring的MockMvc。但是后来我意识到，这种方式将无法确保我正确设置了MVC配置。所以，如果我有这样的控制器：

@Restcontroller
@RequestMapping("/cars")
public class CarController{
    private CarService carService;
    public CarController (CarService service){this.carService = service};
    @GetMapping
    public List<Car> getCar(@RequestParam("filter") String filter){
       if(filter!=null && !filter.trim().equal("")){
          //omitted for brevity
       }
    }
}

并且如果我直接对其getCar方法进行单元测试，即使测试通过了，那也不意味着我的控制器还可以。因此，我开始进行集成测试，而不是进行单元测试。像这样：

mockMvc.perform(get("/v1/cars?filter = Honda"))....  bla bla bla

最近出现了一个问题，我们是否应该首先进行单元测试和集成测试休息控制器。乍一看，在我看来，集成测试最终会检查控制器的正确行为。但另一方面，仅依靠集成测试有多好呢。

Answer 1

我个人从来没有发现单元测试控制器有用。在理想情况下，控制器相对较小，因为它仅调用服务对象的几种方法并返回结果。 IMO单元测试将意味着（过度）使用verify()方法。（即，控制器是否使用正确的参数调用了服务方法。）

例如，在我的案例中，编写良好的控制器方法如下所示：

@LoggingInfo
  @PostMapping(value = "/someRoute",
      produces = "application/json",
      consumes = "application/json")
  @ApiOperation(value = "Some description", response = SomeDTO.class)
  public @ResponseBody
  CompletableFuture<ResponseEntity> someControllerMethod(
      @Validated(ValidationSequence.class) @RequestBody SomeDTO someDTO) {

    return service
        .doSomething(someDTO)
        .thenApply((String var) -> ResponseEntity.ok(ResponseDTO.builder()
            .myField(Collections.singleton(var)).build()));
  }

对该方法的单元测试将在多大程度上为应用程序增加价值？

对我来说，改变游戏规则的是集成测试的使用。事实证明，所有弹簧魔术是否正常工作，例如：

由注释触发的验证器
（不同）验证者的顺序
转化者（例如，看到杰克逊的镜头）
异常处理程序（被注释的异常处理程序实际捕获的引发的异常）

希望这会有所帮助。

在Spring MVC中对控制器类进行单元测试是一种好习惯

1 个答案: