Ability to run Specmatic without a live server (http4k)

[daviddenton]

Is your feature request related to a problem? Please describe.
We're looking at the possibility of creating a module in http4k to support Specmatic, which would allow users to run their http4k applications in both proxy and stub mode without the use of a live server - ie. completely in-memory. This is possible because http4k applications are just functions and can be exercised without sparking up a port. http4k has a large fondness for testing so we're always looking to incorporate any technologies that will help our users get the most from their test suites!

Our idea for proxy mode is to replace the standard Specmatic proxy with a simple middleware filter which would provide access to generating the contracts and then proxied the request/responses to the application . For the stub mode, the current live Specmatic stub (which runs a Ktor server currently) could be replaced with an in-memory http4k server implementation that hooked into the same HTTP stub response mechanics.

Describe the solution you'd like
At the moment, we're looking at the viability of providing this module (http4k-testing-specmatic), so would really appreciate any assistance with our idea and how we could make it work:

Proxy mode - It seems like the Specmatic Ktor Proxy would be fairly simple to implement in http4k as an in-memory middleware (or even server!).

Stub mode - seems more problematic for us due to the HttpStub implementation - there is ContractStub but that exposes HttpClient which is also a class instead of the TestExector interface. HttpStub also seems to have more private (HttpStubResponse) behaviour interacting with the Ktor APIs which would need recreating (and we'd like to avoid duplication wherever possible!). Our plan for the stub would be to provide a JUnit extension which would provide an object which provided the stub HttpHandler (or even just the HttpHandler itself).

Describe alternatives you've considered
If the Specmatic team wished instead for this to be implemented in the library codebase - we definitely don't want to take away from your great work in this area! - then we would be happy to assist providing the http4k expertise in order that the underlying HttpHandlers could be exposed for our users. 🙃

[jaydeepk]

Hi @daviddenton
Thanks for reaching out to us.
We'll have a look at this and get back to you.

[harikrishnan83]

bump

[savagematt]

Would also find this helpful.