Fork me on GitHub
#pedestal
<
2020-05-15
>
Karol Wójcik08:05:56

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?

jdkealy14:05:17

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

ddeaguiar14:05:03

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

jdkealy14:05:37

Let’s say I wanted to get a swagger.json from and upload it to S3. Would you be able to do that without using response-for ?

jdkealy14:05:03

That calls this:

ddeaguiar14:05:16

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

ddeaguiar14:05:14

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

ddeaguiar14:05:43

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

ddeaguiar14:05:08

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

ddeaguiar14:05:27

So can exercise them in isolation

ddeaguiar14:05:16

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

ddeaguiar14:05:15

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

ddeaguiar14:05:18

something like that

ddeaguiar15:05:50

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

ddeaguiar15:05:39

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

jdkealy15:05:50

Thanks a bunch 🙂