This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-22
Channels
- # aws (12)
- # babashka (24)
- # beginners (51)
- # biff (2)
- # cherry (4)
- # cider (2)
- # clj-kondo (4)
- # cljs-dev (19)
- # clojure (70)
- # clojure-australia (4)
- # clojure-europe (39)
- # clojure-nl (4)
- # clojure-norway (6)
- # clojure-spec (9)
- # clojurescript (21)
- # component (6)
- # cursive (18)
- # data-science (9)
- # datomic (18)
- # events (2)
- # expound (4)
- # fulcro (15)
- # graalvm (2)
- # graphql (5)
- # jobs (1)
- # juxt (2)
- # leiningen (8)
- # malli (4)
- # meander (21)
- # nrepl (3)
- # observability (14)
- # off-topic (49)
- # other-languages (1)
- # pathom (13)
- # pedestal (7)
- # rdf (5)
- # re-frame (10)
- # reitit (1)
- # sql (4)
- # squint (30)
- # tools-deps (1)
- # vim (11)
does anyone have a version of io.pedestal.test/response-for
laying around which lets you pass in a context? else I’ll build one 😄
@UBN9SNVB4 the idea of response-for is to call your application as it curl
was calling it
if you implement this feature, response-for will be equivalent to simply call the function handler/the interceptor chain
Hi thanks for the answer @U2J4FRT2T, I had another thought about it and I agree it just calls the interceptor chain, but there is value in testing the “whole chain” with the routes etc. The problem here is session really, the user is expected to have a session. I could make it so that I attach an interceptor which adds a session when I’m in test mode. Then I could still use response-for without any changes