This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (35)
- # beginners (137)
- # braveandtrue (1)
- # calva (33)
- # cider (40)
- # cljsrn (4)
- # clojure (10)
- # clojure-spec (26)
- # clojure-uk (29)
- # clojurescript (18)
- # core-async (6)
- # cursive (1)
- # emacs (2)
- # figwheel-main (17)
- # fulcro (28)
- # jobs-discuss (4)
- # leiningen (1)
- # lumo (19)
- # off-topic (2)
- # om-next (1)
- # reitit (2)
- # rum (8)
- # spacemacs (19)
- # tools-deps (9)
- # yada (3)
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.
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
The minimal change (as of Expectation 2.2.0-rc3) is to change your top-level
defexpect <some-name> (and use
expectations.clojure.test instead of
(defexpect positive-test pos? (compute-value 1 2 3))
Then you can leverage all of the regular tooling around
(expect pos? (compute-value 1 2 3))
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).
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
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
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
not sure about globals in the ui though - reagent's hiccup messes up every scheme I've thought of so far
https://github.com/juxt/edge/issues/38 going to see how posting this works out. Not entirely edge-specific. It's about aero/component integrations.