@deleted-user I would do something like (is (s/valid? ::some-spec a-valid) (s/explain ::some-spec a-valid)) -- untested but should be close.

assert throws an exception which isn't very useful in a test.

To clarify, I see that creating a def inside a defn is considered bad practice, is this because that def will create a new global binding, i.e., that bound var could be accessed anywhere in the namespace? The proper approach (I know this, I'm just clarifying my thoughts) is to use let which creates a new lexically scoped var, that once the let is done, the var is unbound?

yes

ta 😉

@dharrigan not only is it accessible anywhere, but if your function is run concurrently, both instances are mutating the same shared value, a classic source of errors

ooh, that is dangerous

thanks. I was asked by a colleague why not do as I explaining some clojure to him, I think I did okay, but didn't mention about the concurrency issue!

one of the best things about clojure is that if we write normal code, it's automatically thread safe, but that means our definition of "normal code" can't include def inside defn :D

I've been using agents to perform http requests, and I'm wondering how to respect 429s and rate limit myself. Is that possible with vanilla agents, or do I need something else? I can tolerate some (< 15 %) requests not going.

since agent actions are serialized, you could have the agent send itself #(Thread/sleep n) followed by re-sending the same function it was executing

any new actions would get queued up to run after the sleep and the retry are done

@seancorfield: thanks for making this https://youtu.be/CWjUccpFvrg

@johnjelinek Glad you found it useful!

Indeed! I've been using vscode instead of atom, but there's a lot I want to copy from your video.

@johnjelinek Feel free to reach out with any questions you might have about the workflow etc.

👋 anybody here use compojure-api? I'm trying to run https://github.com/metosin/compojure-api-examples

^ this is what I get

the example repo is really old, and likely using an old broken version of unify

Yeah, this came up a few days back -- let me search Zulip for the info...

if you run it with the versions as specified in the repo I would expect it to work

how is compojure-api for building rest api?

i mean, is it good or bad?

Looks like the old version of the lein-ring plugin is probably the issue here -- based on the discussion mirrored to Zulip from February, but I thought it came up more recently...

this came up for me twice this week and was related to an outdated lein-ring plugin. i think you want 0.5.12 maybe?

^ @andrea.imparato There you go!

0.12.5 it seems

💥 thx!

compojure-api is fine for building REST APIs. We use plain Compojure, and JSON middleware at work for our REST APIs.

(so I should probably say "our REST-like APIs" 🙂 )

eheh 👍 yeah I want to use it for a pet project just to practice a bit with web development 🙂

I've had nice success with clj-http-rest

oh, that's for client, not as a server

either is the same result

I'd say, don't be afraid of using words in test names :) like test->maze-constructor-function is perfectly good too

6 months later when it fails and prints that in your console, it may be helpful :)

what's your issue? how is laziness vs strictness hurting you?

@deleted-user Do you mean that you only want the expression in the "message" position to be evaluated if the test fails?

(is (= "Success!\n" (s/explain-str :grid/maze (g/->maze 2 3))))

user=> (t/is (= "Success!\n" (s/explain-str even? 42)))
true
user=> (t/is (= "Success!\n" (s/explain-str even? 43)))

FAIL in () (NO_SOURCE_FILE:1)
expected: (= "Success!\n" (s/explain-str even? 43))
  actual: (not (= "Success!\n" "43 - failed: even?\n"))
false
user=> 

(reify Object (toString [_] (s/explain-str even? 43))) -- but the resulting message is wrapped in #object[ ... ]

Actually, is is a macro so I suspect it doesn't evaluate the msg form unless the test fails... let me verify that...

Ah, that's a shame 🙂

Moin, I'm trying to import a java lib from maven with leinigen. The library is this one: https://github.com/prometheus/client_java

[io.prometheus/simpleclient "version"] should be ok right?

[io.prometheus/simpleclient "0.6.0"] ok so worked.. First time I import a java lib 😁 I did a typo before that's why didn't worked.. 😁

@deleted-user Something to consider if you want to test with specs is to use expectations/clojure-test which provides more expressive tests. For example:

(! 537)-> clj -Sdeps '{:deps {expectations/clojure-test {:mvn/version "RELEASE"}}}'
Clojure 1.10.1
user=> (require '[expectations.clojure.test :refer [expect]])
nil
user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/def ::foo even?)
:user/foo
user=> (expect ::foo 42)
true
user=> (expect ::foo 43)

FAIL in () (NO_SOURCE_FILE:1)
43 - failed: even? spec: :user/foo

expected: (=? :user/foo 43)
  actual: (not (=? :user/foo 43))
false
user=> 

You can use expect in place of is inside deftest.

I started using Expectations years ago, after seeing it presented at Clojure/West. Eventually (as with so many libraries!) I ended up taking over as maintainer. But it always bothered me that the core Expectations library is not compatible with clojure.test. That's what I wrote expectations/clojure-test

This one https://github.com/clojure-expectations/clojure-test

It's basically the syntax from the original Expectations library (that first link), transplanted into the clojure.test environment.

We use it for almost everything at work. Works with Cognitect's test-runner, for example. Works with Cursive as well I believe (which does some fancy stuff with test failures).

It runs a clojure.test-compatible suite.

There are lots of test runners out there.

clojure.test needs a test runner in order for you to run tests from the command-line.

lein test is another test runner (again, expecting something clojure.test-compatible).

(CIDER is also a test runner, among other things)

There's an #expectations channel if you get deeper into that library and have questions. I'll notice them more easily there.