m110
commented
3 years ago Hey @Djerys!
Our approach usually is to base ports testing on:
Both use HTTP clients to call real endpoints, so they test the ports layer among other things as well.
It depends on the project though. If you look at trainings http handlers there's very little logic there (and that's the way we want it). The layer just unmarshals the JSON request, maps it to the application command, and marshals the JSON response, if any.
You could argue that we don't test that the mapping is correct. So we could add mocks for the application layer and assert that the function was executed with correct parameters. But then we would basically just repeat the same code twice, and it would need to be updated every time someone changes the application handler. Tests like these don't give you much value, and are pain to deal with, so we avoid them most of the time.
Of course, you could also have longer handlers, that don't have any application logic, but some port-specific complex scenarios (things like authentication, doing something based on HTTP headers, HTTP cache, and so on). In that case, I think it's perfectly reasonable to add unit tests checking this code, preferably extracted to a separate function, so you don't need to deal with the http.HandlerFunc interface.
If you really need to test the entire handler, httptest provides quite nice tooling for it, so at least you don't need to spin up an HTTP server.
I hope this helps. I'm happy to hear you like the project! :)
Djerys
Hi, your project is just wonderful. I would like to know your opinion on the unit tests for the HTTP layer in service. After all, you need to make sure that your API meets the requirement, right? Also it would be useful in regression testing after refactoring this layer. If you think you need such tests, do you need to mock the application layer?