Fork me on GitHub

Mornin' 🙂 Plans for the weekend before Xmas?


nothing more advanced than seeing what's going on in clojure land


it's early here and everything is quiet


I've been working on Expectations (again, after a long break).


I'm really keen to find a way to make it work seamlessly with clojure.test-based tooling... this is now my fourth run at it.

👍 8

If you could do that it would be awesome Sean. Expectations not playing well with clojure.test tooling is the reason I stopped using it.


The main stumbling block is the lack of consistently named tests. So you have to give up the notion of simple, unnamed tests in order to fit in with clojure.test's ecosystem.


The minimal change (as of Expectation 2.2.0-rc3) is to change your top-level expect to defexpect <some-name> (and use expectations.clojure.test instead of expectations).


(defexpect positive-test
  pos? (compute-value 1 2 3))
instead of
(expect pos? (compute-value 1 2 3))
Then you can leverage all of the regular tooling around clojure.test.


The problem with 2.2.0-rc3 as it stands is that it still tries to use all of Expectations' comparison/reporting machinery which doesn't mesh well with any tooling that monkey-patches clojure.test and doesn't always produce good error messages (`clojure.test` has a fairly opinionated approach that is a bit narrow for Expectations' original concepts there).


The new approach is to simply rewrite the defexpect/`expect`/`more`/… forms into deftest/`is` forms with a tiny bit of sugar so that you get reasonable error/failure reporting -- that tools like Cursive can use (hopefully) -- and which can be modified by any of the standard clojure.test plugins (like Paul Stadig's Humane Test Output etc).


I'm also planning to do some more "hammocking" on java.jdbc2 / next.jdbc...


And (for fun) it's our 19th wedding anniversary on Saturday 🙂

❤️ 4
🎉 8

test stuff was bugging me a few weeks ago - in particular the asymmetry between cljs async tests, with the done callback, and clj async tests which tend to deref or <!!


it makes it hard to write tests for .cljc libs


Interesting. I haven't worked with cljs for 3-4 years now so I'm not up on what's possible and what's different.


Expectations is mostly cljc but right now the clojure.test stuff is very heavily macro-based.


I came up with a solution, it's not so pretty... the clojure.test stuff uses dynvars to pass context, which doesn't work so well for async code which can jump between pool threads


dynvars are the devil's work


Yeah, I've been working for seven years to eliminate them from every part of our code 🙂


I don't think we have any dynvars in our codebase... we have some globals in the ui and an app-context parameter in the backend is like to get rid of


I think a reader monad is the way to get rid of the app-context parameter


not sure about globals in the ui though - reagent's hiccup messes up every scheme I've thought of so far

dominicm10:12:40 going to see how posting this works out. Not entirely edge-specific. It's about aero/component integrations.


Fwiw, a comment indicating which usage you prefer for any arbitrary reason is valuable 😊 it's no point me picking a solution if it turns out that it's not easy to understand.