Official hato-fake repo?

[vincentjames501]

It would be awesome if there could be an official hato-fake repo which would support intercepting requests.

Inspiration:
clj-http-fake
http-kit-fake

I think either adding a repo like this or updating the documentation to reflect recommend patterns would help complete the testing story of hato.

Thanks for the awesome lib!

[gnarroway]

Thanks for raising this.

I’ve had a look at the repos and I think if there is sufficient demand then a community supported hato version will be fine and I would be happy to mention it in the docs.

Personally I do not use this type of testing. I will typically put things that communicate externally (to an api, db etc) in a boundary namespace with a protocol.

• the boundary itself will be covered by integration tests connecting to real instances, as well as unit tests if there is any interesting logic
• business logic has these protocol implementations injected so for unit tests, the entire boundary can be mocked/stubbed, rather than the implementation (specifics of an HTTP request)
• end to end tests will again typically use real instances, or if I really need some specific behavior from a dependency, I can spin up a fake instance and point to it.

Maybe these interceptor libraries would be useful for the end to end tests as described above, but since I do not use them I don’t really have a strong opinion on how such libraries would behave.

[onetom]

Some example would be still great, so we can learn about these techniques by example.
I would be interested how you name your protocols?
How you make them namespace-reloading friendly?
How would test-specific mock implementations of these protocols would look like?

But regarding faking, I think turning the current hato.client/request* function a request option, similarly to the :http-client, would be a pretty good solution.
Then test-specific fakes could be implemented via clojure.core.match/match, which trivially supports features equivalent to spying, mocking and stubbing.

[onetom]

On further thinking, it would be still nice to keep the functionality of a cookie jar in a fake implementation. In such cases, the faking with clojure.core.match wouldn't be that straightforward...