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?
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
in CLJS it's a macro
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. đ
I need it for run-all tests
.
And the regex works when using it with, say, re-find
So, itâs the run-all-tests
macro that seems to need a literal regex?
@pez can we see the code please?
(let [rp (re-pattern "foo")] (cljs.test/run-all-tests rp))
@pez in cljs run-all-tests
is a macro so it only takes a literal regexp, not a symbol.
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.
Yeah, so that doesnât really say to me that it needs to be a literal regex.
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).
Awesome. Thanks for the help understanding this!
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 instead gives you a map with all the test data in CLJS
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.
koacha has something similar
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.
Thanks a lot for those pointers. We have our own test-runner and it it giving us grief, so a colleague started to try rewrite parts of it and then we ran into this problem. Getting out of macro hell and into data land is exactly what I want.
What Iâd really like to do is move the project over to shadow-cljs, but so far it has said no to my attempts. Inching my way there, so our test runner wonât be needed eventually.