Clojurians Log v2

FWIW the :node-test target has some very limited command line options that could be extended if it makes sense for your project

the :node-test build produces a runnable which actually runs the tests, so the command line options are for that

script.js is such a output here

node script.js --list
Namespace: demo.foo-test
  demo.foo-test/foo

node script.js --test=demo.foo-test

Testing demo.foo-test

FAIL in (foo) (demo/foo_test.cljs:5:7)
expected: (= 1 2)
  actual: (not (= 1 2))

Ran 1 tests containing 1 assertions.
1 failures, 0 errors.

node script.js --help also lists those options

> Right now, the Shadow-cljs support only runs "the whole project", regardless of which bricks actually need testing.

not actually sure what this means, but you can preselect which tests to actually run

you can also preselect which namespaces to actually compile by adjusting the :ns-regexp option (or controlling the classpath and just not having something present in the first place)

> currently no way to pass aliases to the shadow-cljs compile process (and this probably needs a way to specify -A vs -M?)

if you are deps.edn based anyway then you do not need to use the shadow-cljs command at all. just run it however you run any other clojure command

clj -M:whatever:aliases -m shadow.cljs.devtools.cli compile test is same as npx shadow-cljs compile test + alias config in shadow-cljs.edn

but there is also a -A option for shadow-cljs to pick aliases, but I just recommend using the clojure command line directly

@thheller Thanks. I noticed there was :autorun true so shadow-cljs could automatically run the node test so I handled that in my test runner. :node-test and :karma are the only two :target values that seems to have simple, standard test runs that I could incorporate easily. Re: :ns-regexp -- I saw that but it is "configured" on a per-build basis. poly test works by figuring out what files changes and therefore which "bricks" (modules) need to be tested and therefore which projects need to be tested -- testing is always run in each affected product context, but for Clojure and for the Olical cljs runner, only the namespaces which "need to be tested" are considered for tests to run. Incremental testing. So that is always done dynamically: each run of poly test may run a different set of tests, depending on what has changed since the last "tagged" version in your repo. Re: aliases -- good to know about running shadow-cljs via clojure if you need anything fancy, but I thought it would be faster to run it via npx than via the JVM? At least in terms of startup?

no difference in startup speed if a new JVM is started. if shadow-cljs is already running in server mode that is bypassed, but I don't think thats true for your test setup

:autorun is bad for actual testing since the process exit code is lost

For the node test run, can I specify --test= multiple times to run tests in multiple namespaces?

Usage:
  --list (list known test names)
  --test=<ns-to-test>,<fqn-symbol-to-test> (run test for namespace or single var, separated by comma)

Ah, comma-separated. Awesome. I can implement the restricted nses list for :node-test then! Thank you!

https://shadow-cljs.github.io/docs/UsersGuide.html#config-merge

shadow-cljs release test --config-merge '{:ns-regexp ...}'

or just modify the config via clojure API

fwiw the build config can also just take a list of namespaces, doesn't need to be a regexp

Hmm, thanks. Since the test runner will be running npx shadow-cljs compile test for each test run, using --config-merge might work. And that approach would cover both node and karma since test selection would happen at compile time?

yes

shadow-cljs release test --config-merge '{:namespaces [foo.bar foo.baz]}' if you prefer over a regexp

I assume tho' that :ns-regexp "bar-test,baz-test" would also match foo.bar-test? So ^ / $ anchors would be needed to avoid ambiguity?

Oh!

That's even better. Awesome.

namespaces overrides :ns-regexp if both are set

Nice.

Is there any difference between compile and release for creating runnable tests?

compile is an unoptimized "dev" build. release is closure optimized

For testing, is there much speed difference? Is it worth testing via both to ensure optimization doesn't break behavior?

depends on what kind of testing you are talking about. for CI I would always recommend release, not because of size or speed but because its closer to how you'll actually be using the real code in production/release envs

for dev time automated testing compile or watch is fine. compiles are faster, run time speed is maybe 10% slower

Okay. I'll make sure there's an option for folks to select release so they have control over that. For Polylith, that means something in its test-config so that different testing profiles can be selected via the CLI: poly test with:shadow-release for example, and the :shadow-release config would have :shadow-build (to select the build target) and maybe :shadow-optimize (as :dev or :release). Shoehorning all this into Polylith's machinery to provide both flexibility and automation is challenging in some areas 🙂