I made a PR to malli which makes sci optional: https://github.com/metosin/malli/pull/210 The tests are failing, but this is only because the order in which namespaces are loaded is random. sci.core needs to be loaded first. But since sci.core is now optional, the tests have to be refactored accordingly anyway. Just putting this here in case someone has ideas about it.
@borkdude seems like a good case for using a hook? that's the right place to do "global" setup
actually there's a preloads plugin as well which is an even better fit (thanks @danielcompton for that one)
I was thinking of that one, but it only works in CLJ?
oh snap these are cljc tests? that's tricky
you could still do it with a hook, but it's not as trivial as you'd be dealing with the communication with the client
I think the better option for malli is to make specific namespaces where sci is required and not in others. But that will still not test cases that should work absolutely when sci isn't there, since the randomization might cause to be loaded first in some other ns
you can also turn off the randomization
So maybe the only way out is to use different classpaths for different tests
or have custom sorting logic
right now I've put a (:require [sci.core])
in core-tests.cljc, just to get it working
but if we have custom sorting, we can run the tests without sci first, but I expect that won't work, since it won't guarantee that some other namespace will still load sci .. or something. it's not transparent to me how kaocha handles this
kaocha-cljs just sends (require ...)
forms to a prepl
each namespace gets required as it gets run
ok, then the custom sorting will actually work
just out of curiosity: how does kaocha test optimized builds? does that also work with prepl?
can you somehow make this explicit? have a way to tell the dynaload/lazyvar stuff to pretend sci isn't there?
kaocha-cljs does not currently test optimized builds, that's one of the reasons we're taking a different approach with chui/kaocha-cljs2
ok
I'm trying to find the custom sorting in the docs
that's not documented as such, you'll have to look at the randomization plugin and take it from there
https://github.com/lambdaisland/kaocha/blob/master/src/kaocha/plugin/randomize.clj
https://github.com/lambdaisland/kaocha/blob/master/src/kaocha/plugin/randomize.clj#L47-L53
either do it this way with a plugin with a post-load
hook, or use the hooks plugin and implement a test-plan -> test-plan
function that you reference
{:plugins [:kaocha.plugin/hooks]
:kaocha.hooks/post-load [my.kaocha.hooks/custom-sort]}
you can use --print-test-plan
to better understand what's being passed there, basically it's a map which has :kaocha.test-plan/tests
, which is a sequence of "testables" corresponding with the test suites configured in tests.edn
. Each of these in turn has :kaocha.test-plan/tests
which correspond to namespaces
I'll wait for what @ikitommi thinks of this, before putting too much time in it. Maybe it's better to split out all the sci-related tests into one namespace, or something
I was mostly doing this PR as an example how to do it, but this is turning out into a bit of a rabbit hole 🙂
I have to say it's an impressive hack 🙂 if someone had asked me how to do optional dependencies like this in cljs I probably would have said "can't be done"
it's just a hack I stole from spec
someone should do a blog post about it 😉
I might pull this apart into a separate lib, so more projects can benefit
and then document how it works in the README
👍
Does kaocha-cljs work with target-bundle projects?
Or maybe I should try kaocha-cljs2?