I've been meaning to contribute some/all of the co...

# http4k

[fredrik.nordin]

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.

[dave]

absolutely 100% interested in anything that allows people to make their tests nicer. http4k-testing-openapi ? 🙂

[fredrik.nordin]

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

[dave]

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

[dave]

(since it's generated at runtime)

[fredrik.nordin]

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

[fredrik.nordin]

But it should be trivial to send a request to the spec handler in the contracts module to get the spec before that tests run. Don't even need to start the server to do that

[dave]

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

[fredrik.nordin]

Exactly my thought

[fredrik.nordin]

Being symmetrical an all, it SHOULD then be trivial to use it on the server side to validate incoming requests, with only minor modifications 🤞

[dave]

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.

[fredrik.nordin]

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

[fredrik.nordin]

And asserting headers, status, etc

[fredrik.nordin]

Alright then, I'll try to find some time over the next few weeks to get an initial PR submitted

[dave]

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)