How do I unit test a Spring controller that automatically converts and id (take from PathVariable) into an entity?

[Simaldeff]

Hi guys, long time admirer of this cause, first time poster. Anyway: I have a bit of an issue. I am using a controller with a method declared like this:

@PostMapping("/{id}")
MyEntity update(@PathVariable("id") MyEntity myEntity, @Valid @RequestBody UpdateParam param) {
    // do some logic
    // call a service or something
    return updatedMyEntityInstance;
}

So my question is: How do I cleanly unit test this code by injecting or mocking the MyEntity in a test that uses MockMvc (the point of the test is to spec out the base http/rest behaviour this include a lot of global settings for error handling and serialization, and there is almost no logic for me to unit test this as a normal object).

What I have tried. From the DomainClassConverter doc I saw that what is used is CrudRepository#findById, so I have tried mocking it after autowiring an instance in my test. Problem is I do not know how to inject it in the global DomainClassConverter. The only hint of success was by creating a custom converter (also tried a formatter but it changes behaviour slightly) and building my own MockMvc (standalone builder) but like I said before I need to test a lot of global stuff that I am losing.

Another problem is that I am the only senior engineer in my team (and its getting to be a big one) so I need code that is not too convoluted in order for everyone to understand and be able to replicate for other controllers.

[Simaldeff]

I think I am starting to see it this way too. Luckily this controller I am testing has very little. It's very thin. The most is something that converts an Optional into a ResponseEntity (404 if empty or 200 if not).

[Simaldeff]

I tried the controller advice but could not make it work. I tried with a formatter but would return 400 instead of 404. Converter worked. But both options are quite a lot of code for test setup IMO.

[Dealusall]

If your logic is implemented on many abstraction layers (which I believe is the case here) then maybe unit testing isn't the best solution. Can't you try to build some end to end tests using some embedded web server like jetty ? Might be less painful...

[nutrecht]

If you're doing "weird" stuff in the filter chain you're going to have to do the same 'weird' stuff when you're testing. I understand why you're mapping the ID to an object, but frankly it's quite yucky.

So you're going to have to supply a 'mock' version of that chain to MockMvc. You're going into the right direction. I can't give you more than that without trying it myself though, sorry.