This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-22
Channels
- # 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)
måning
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.
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
...
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
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.