我曾经像其他任何普通的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
最近出现了一个问题，我们是否应该首先进行单元测试和集成测试休息控制器。乍一看，在我看来，集成测试最终会检查控制器的正确行为。但是另一方面，仅依赖集成测试有多好。
我个人从来没有发现单元测试控制器有用。在理想情况下，控制器相对较小，因为它仅调用服务对象的几种方法并返回结果。IMO单元测试将意味着（过度）使用该verify()方法。（即，控制器是否使用正确的参数调用了service方法。）
例如，在我的案例中，编写良好的控制器方法如下所示：
@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()));
}
对这种方法进行单元测试将在多大程度上为应用程序增加价值？
对我而言，改变游戏规则的是集成测试的使用。此处显示所有弹簧魔术是否正常工作，例如：
希望这可以帮助。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句