Clojurians Log v2

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.

I’m building my own framework 😎

Not for APIs, I’ll leave that to Apex, but for web apps

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

I'm not sure what property you're really testing by mocking http though :thinking_face:

Yeah long story 🙂

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

Also, where is the openid part in Apex tested?

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.

You might be wrong 🙂

Anyway, i’m not here to convince anyone

Do you know the VCR approach in ruby?

Haha. I'm now terrified at the idea of you importing all your dependencies' test folders

I don't, I'm guessing it's like clj-vcr though

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

This includes dns lookups

I’m still missing a VCR solution, but I’m getting there

I wonder if a jvm agent would work for that.

Would that work in parallel on the same JVM?

I have never tried it. It sounds scary 🙂

If you were really crazy you'd use a ld preload 😀 that works on any executable.

Something like sockify pointing at a custom socks5 server would give you total assurance.

You think i’m not serious I guess 🙂

This guy understands me 🙂 https://www.youtube.com/watch?v=ikLFUmY70u8&t=1945s

No, I'm not teasing. I actually think sockify is a good idea.

Ok I don’t know enough about it. Is it practical though?

I'm thinking out loud: what other ways you could capture external traffic and transform it.

I don’t know, i’ve solved it by using Clojure protocols

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.

I have no idea what LD preload is

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

Ah yeah that would be super useful for lowlevel programming

If you stay at the http layer, things are still simple enough to stay away 😅

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

Btw I feel I have holistic control in my current setup

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.

Fair enough

I don’t understand why it’s uncommon though

In ruby it wasn’t

Well, it's okay until you use a java library which doesn't support your choice of clojure http client? 😝

Yeah that’s sucks, I’ll have to use another library

There are a few cases where I have to surrender

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

I can sleep at night 🙂

I hope I can convince enough people at some point

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?

Does it matter what language you use?

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? 😅

I'd probably test the functions which process the request/result.

But these are internal tests. Internal to the library.

In my experience there are moments when external API’s suddenly change. This moment you want to detect as an external change

First problem is detecting is: schedule full integration tests

Second problem is knowing that it’s not your code: VCR-ed integration test

You could do it with manually processing the request/result, but there is a lot of labour there

I still don’t use a VCR approach in Clojure, but I strongly miss it

That's interesting. These aren't exactly tests you'd run at check-in then?

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

Scheduled would have been better

We had many broken builds due to timeouts of the APIs

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.

Yeah true

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

But I have never seen this in practise

So if your business depends on it, you probably want to do it this way

Thanks for challenging me 🙂

Need to get some work done now

Honestly - it's all for me 😀 I want to learn about this testing approach I don't entirely understand!

Ok let me finish this framework and you will see it

And also watch that presentation. He has similar ideas

In an application I try to make everything deterministic. That means: random numbers, http, time and anything that is related

It makes live much easier

(and your tests faster)

hello, is this an appropriate channel to inquire about the tick time lib?

Yes

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:

(defn date? [d] (= (type d) (type (t/date))))
(comment (date? (t/date)))

(defn date-time? [d] (= (type d) (type (t/date-time))))

Right though. You might want to use instance?

i don't believe the classes are exposed via the api

ah, i see what you mean

(defn date? [d] (instance? (type (t/date)) d))