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?