This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-16
Channels
- # aleph (3)
- # announcements (14)
- # babashka (16)
- # beginners (85)
- # calva (6)
- # cider (9)
- # clojure (42)
- # clojure-australia (8)
- # clojure-europe (30)
- # clojure-nl (4)
- # clojure-uk (29)
- # clojuredesign-podcast (7)
- # clojurescript (25)
- # cursive (4)
- # data-science (1)
- # datomic (31)
- # emacs (1)
- # events (1)
- # fulcro (16)
- # instaparse (2)
- # java (37)
- # kaocha (3)
- # malli (3)
- # meander (19)
- # membrane (7)
- # off-topic (13)
- # pathom (4)
- # pedestal (10)
- # re-frame (17)
- # reveal (3)
- # rewrite-clj (1)
- # ring (9)
- # shadow-cljs (17)
- # spacemacs (2)
- # sql (34)
- # tools-deps (88)
- # vim (4)
I get an compile error about java.lang.Symbol
not being able to be interpreted as a regex when creating the regex using re-pattern
. What am I not understanding?
user=> (doc clojure.test/run-all-tests)
-------------------------
clojure.test/run-all-tests
([] [re])
Runs all tests in all namespaces; prints results.
Optional argument is a regular expression; only namespaces with
names matching the regular expression (with re-matches) will be
tested.
If you mean, does it need to be a literal, or can it be an expression that evaluates to a regex, I am pretty sure it could be an expression that evaluates to a regex
I added a not to the clojuredocs page about run-all-tests now. https://clojuredocs.org/clojure.test/run-all-tests Would have helped me a lot to find such a note when this bit me. 😃
@pez can we see the code please?
@pez in cljs run-all-tests
is a macro so it only takes a literal regexp, not a symbol.
Thanks. Does it follow from “it is a macro” that “it only takes literals”?. Newbish question, maybe, but I am under the impression that I use macros all the time, passing in symbols.
True. CLJS sometimes uses macros for things that are functions in CLJ because CLJS is more restricted
@pez it kind of follows yes. of course it depends on what the macro does. most macros are happy to use whatever you provide since they don't actually want to eval the argument and just place it somewhere else in their output. the cljs.test macros however evaluate at compile time to filter the available tests/namespaces since that info only exists at compile time and not at runtime (unlike clojure).
I don't know what you are trying to do exactly but maybe the stuff I have in shadow.test.env/get-test-data
is useful for you https://github.com/thheller/shadow-cljs/blob/d80ee477020c91fa441bb205f52967c1100e2526/src/main/shadow/test/env.clj#L7
that you can actually filter like any other data. all the shadow-cljs test things use this. makes things much more flexible without the macro hell.
still has the macro problem in that it can't dynamically discover tests but using an dynamic regexp works just fine ;)
used like this https://github.com/thheller/shadow-cljs/blob/d80ee477020c91fa441bb205f52967c1100e2526/src/main/shadow/test/node.cljs#L15-L18
or just use a test runner? I've heard good things about kaocha but for CLJS I found it problematic a couple of times. I've been using https://github.com/Olical/cljs-test-runner which is much simpler (as in more basic) and I stuck with it since.