This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-30
Channels
- # announcements (5)
- # beginners (90)
- # cider (15)
- # clara (1)
- # clj-kondo (2)
- # cljs-dev (17)
- # clojars (8)
- # clojure (132)
- # clojure-europe (14)
- # clojure-nl (5)
- # clojure-uk (57)
- # clojurescript (39)
- # code-reviews (44)
- # conjure (6)
- # core-async (6)
- # cursive (20)
- # data-science (1)
- # datomic (13)
- # fulcro (11)
- # graalvm (6)
- # graphql (6)
- # helix (10)
- # joker (2)
- # kaocha (37)
- # leiningen (24)
- # malli (15)
- # off-topic (13)
- # pathom (18)
- # pedestal (14)
- # re-frame (67)
- # reitit (5)
- # ring (13)
- # ring-swagger (4)
- # sci (41)
- # shadow-cljs (33)
- # slack-help (5)
- # spacemacs (1)
- # sql (34)
- # tools-deps (64)
- # vim (171)
- # xtdb (3)
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)
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
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
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
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#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"
Does kaocha-cljs work with target-bundle projects?
Or maybe I should try kaocha-cljs2?