This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (94)
- # beginners (76)
- # calva (24)
- # cider (24)
- # clj-kondo (1)
- # cljs-dev (16)
- # cljsrn (45)
- # clojure (135)
- # clojure-europe (9)
- # clojure-france (5)
- # clojure-germany (2)
- # clojure-italy (12)
- # clojure-losangeles (13)
- # clojure-nl (3)
- # clojure-portugal (54)
- # clojure-uk (20)
- # clojurescript (55)
- # conjure (67)
- # core-async (5)
- # crux (33)
- # cursive (2)
- # datomic (7)
- # docker (7)
- # duct (22)
- # emacs (16)
- # fulcro (34)
- # graalvm (15)
- # hoplon (1)
- # instaparse (1)
- # jobs-discuss (3)
- # juxt (94)
- # luminus (1)
- # meander (4)
- # off-topic (13)
- # pathom (4)
- # pedestal (1)
- # ring (3)
- # ring-swagger (2)
- # shadow-cljs (61)
- # spacemacs (17)
- # specter (2)
- # sql (23)
Maybe it's not necessary to mock the http client, you don't need to test the library. Just swap the middleware out when testing.
And I would like to use the OpenId code in other places too. I think it’s just better to do it this way
I’ll not force my ideas upon others, but I’ll be forced to create my own library as this style of development requires and all-in approach
If I’m integrating an open Id library into my application, I need to deal with this in my tests. My tests are setup to mock http by using protocols. So I need the library to satisfy these protocols. Swapping middleware is one way, but I think there are better ways
I mean from a higher level. There's not much point faking openid interactions when you can bypass them for the purposes of testing. The only reason to mock openid is to ensure the library does what it says. But I doubt you test all your libraries this way.
Haha. I'm now terrified at the idea of you importing all your dependencies' test folders
Haha no I mean, i’m not assuming the libraries are well-tested. So i’m using integration tests to verify it works the way i think it works
And I try to make this practical by having a well-tested http layer that runs in memory
Something like sockify pointing at a custom socks5 server would give you total assurance.
This guy understands me 🙂 https://www.youtube.com/watch?v=ikLFUmY70u8&t=1945s
I'm thinking out loud: what other ways you could capture external traffic and transform it.
Like, using an LD preload would mean this part of your tests needs to run in a separate JVM. But it would give you a high assurance that nothing is happening without you knowing.
For me it works to solve it at the Clojure level, that’s also my preference. The thing that I deeply understand
It's a way to override the function calls being made to the operating system. Eg fstat, fopen, etc
You could also go at the JVM level to set a socks proxy, that would allow you to work at the http layer.
Then you write a small socks proxy which calls you to say there's a http request, what do you want to do?
Why are you telling me to swap middleware and now you are telling me to go to the operating system? :rolling_on_the_floor_laughing:
Going lower lets you have very holistic control I guess :). Socks is probably the best layer in terms of minimum work & broad coverage.
Might be true hehe. But is something I’m not comfortable with (yet). I’m fine in this position
I would love to see someone explore this field for me though! I’m not ready yet
I'm exploring this (in words) because I think that adding flags for http clients adds complexity. Given how uncommon the kind of testing you're aiming to do is, I'm trying to think of other ways it could be achieved.
Well, it's okay until you use a java library which doesn't support your choice of clojure http client? 😝
Yeah, that's an interesting question. It might have something to do with global variables perhaps, or maybe just culture. Dunno.
I prefer to go the painful route of rewriting something or searching for libraries that fit, than to adapt my way of building applications
One reason I think VCR is not more popular in Clojure is that Clojure (and other functional languages) work on composition rather than hierarchy.
If you build an integration with an external API, what are other ways to properly test this?
I see only one option: scheduled full integration tests + VCR-ed integration test to distinquish internal failures from external failures
So let’s we would be building something like let say an openid connector, how can we test this reliably? 😅
In my experience there are moments when external API’s suddenly change. This moment you want to detect as an external change
You could do it with manually processing the request/result, but there is a lot of labour there
You'd run them in production? - and monitor the results conform to some spec at all times?
You can run VCR tests anytime. The full integrations tests are too slow and once a day on CI should be fine
A long time ago I was working on a service that had integration with Twitter, Facebook etc. We would run full integration tests with real accounts
It wasn’t perfect, so we did VCR tests locally and full integrations tests on CI
Stepping back. Unless you updated your OpenID library / changed your config, you know the failure is external? e.g. the integration tests were fine for 7 days since the last commit and then failed.
In a business application, it is very likely that you had many updates in those 7 days
I guess the question is whether you are actually working on the openid code or not
If the library underneath has these tests, than you don’t have to do it as well
Honestly - it's all for me 😀 I want to learn about this testing approach I don't entirely understand!
In an application I try to make everything deterministic. That means: random numbers, http, time and anything that is related
cool, thanks. I am writing specs for some data, and want to validate that some fields are some tick data types, I didn't see any functions in the lib, so I am making my own like so:
just wanted to see if there is some other way to check for these provided in tick
(defn date? [d] (= (type d) (type (t/date)))) (comment (date? (t/date))) (defn date-time? [d] (= (type d) (type (t/date-time))))