Clojurians Log v2

Imo faking the request should be considered bad practice. Why do people test whether http library like pedestal works? Shouldn't we test the domain logic instead?

That’s my issue is because of all the chained interceptors (I’m brand new to pedestal and interceptors ), I don’t understand how to get the result of an endpoint without using response-for

@jdkealy you can also test an interceptor or subset of interceptors directly

Let’s say I wanted to get a swagger.json from <https://github.com/oliyh/pedestal-api/blob/master/src/pedestal_api/swagger.clj#L10> and upload it to S3. Would you be able to do that without using response-for ?

That calls this: <https://github.com/frankiesardo/route-swagger/blob/master/src/route_swagger/interceptor.clj#L21>

IDK, that’s less of a pedestal concern. While working in the repl during development I don’t use response-for . I limit the usage to testing. In the repl I work with small fns which handle the core logic of the system

I don’t think end-to-end testing is bad practice but it should not be applied as a hammer either.

I also tend to spin up my service and send requests to it during dev as well. Changes being applied as I build. But I do that when I’m interested in any wiring I’ve done

When working on interceptors, I’m most interested in Context in/out

So can exercise them in isolation

If an interceptor requires some setup (i.e., data in context) I either fake that or add the interceptors that bring in that data to the interceptor chain that gets executed

(def result-ctx (io.pedestal.interceptor.chain/execute {} [interceptor1 interceptor2 …])

something like that

The concept of Chain Provider is at the core of Pedestal http://pedestal.io/reference/chain-providers#chain-providers

@jdkealy glad to see you giving Pedestal a spin! Hopefully this info helps.

Thanks a bunch 🙂