I've been meaning to contribute some/all of the code we did for one of the recent projects, where we integrated https://bitbucket.org/atlassian/swagger-request-validator with http4k, so that we could validate the responses from the app against an OPenApi spec in the functional tests. The benefit there is that the tests are then more about the functionality than validating the structure, headers, status etc, which is instead automatically handled by the library. It really makes the tests nice and clean, not full of json payload validation code. Would there be an interest in having that as an official module in the repo? It can also easily be used on the server side, to validate incoming requests against the spec, which is something that module could also provide.

absolutely 100% interested in anything that allows people to make their tests nicer.

http4k-testing-openapi

? 🙂

Yes something like that. Might pick a slightly different name, so that we can include the server side functionality too, without making it specific to testing. Otherwise, just have two modules, which is not as nice

how did you get hold of the openapi doc to validate the responses against?

Well, we didn't use the contracts module in the app, we had a manually created spec that we validated against. But what I wanted to do is to use the auto-generated one instead, which would be swanky

you could add the validator as a filter around the app, which would be boilerplate free

Exactly my thought

with regards to

It really makes the tests nice and clean, not full of json payload validation code

, we've switched to JSON approval tests as a way of getting around this.

Yes I've seen it and used it (nice). This would be an alternative approach, which takes care of automatically validating the request/response against the spec, without having to create approval files

awesome 🙂 . if you're worried about headers, you can also spit out the entire response using toString() and use that to approve against, although i'd probably only do that against individual endpoint unit-tests. as doing it via the app might be a hassle (due to dynamic headers)