Fork me on GitHub
#clojurescript
<
2020-11-16
>
pez11:11:40

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?

pez11:11:31

I need it for run-all tests.

pez11:11:49

And the regex works when using it with, say, re-find

pez11:11:52

So, it’s the run-all-tests macro that seems to need a literal regex?

borkdude13:11:45

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.

pez14:11:51

Yeah, so that doesn’t really say to me that it needs to be a literal regex.

andy.fingerhut21:11:18

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

borkdude21:11:35

in CLJS it's a macro

pez07:11:36

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. 😃

Louis Kottmann11:11:43

@pez can we see the code please?

pez11:11:32

(let [rp (re-pattern "foo")] (cljs.test/run-all-tests rp))

thheller12:11:35

@pez in cljs run-all-tests is a macro so it only takes a literal regexp, not a symbol.

pez14:11:30

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.

borkdude14:11:41

True. CLJS sometimes uses macros for things that are functions in CLJ because CLJS is more restricted

thheller15:11:04

@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).

pez16:11:59

Awesome. Thanks for the help understanding this!

thheller16:11:40

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

thheller16:11:52

that instead gives you a map with all the test data in CLJS

thheller16:11:35

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.

thheller16:11:09

koacha has something similar

thheller16:11:23

still has the macro problem in that it can't dynamically discover tests but using an dynamic regexp works just fine ;)

borkdude16:11:13

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.

pez16:11:12

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.

pez16:11:23

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.