This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (39)
- # beginners (91)
- # cider (9)
- # clj-kondo (10)
- # cljsrn (1)
- # clojure (54)
- # clojure-europe (45)
- # clojure-italy (2)
- # clojure-nl (1)
- # clojure-spec (33)
- # clojure-uk (21)
- # clojurescript (7)
- # core-typed (1)
- # crux (23)
- # cursive (9)
- # data-science (1)
- # datomic (2)
- # docker (3)
- # emacs (11)
- # figwheel-main (11)
- # fulcro (19)
- # java (1)
- # juxt (1)
- # kaocha (68)
- # malli (7)
- # meander (5)
- # off-topic (76)
- # pedestal (1)
- # re-frame (6)
- # reveal (1)
- # rum (2)
- # shadow-cljs (48)
- # sql (6)
- # tools-deps (47)
- # vim (8)
Hey @plexus, did you create another a cljs test runner that is not Kaocha? I have vague recollection of this but now can't find anything
which is really just a piece of the puzzle for kaocha-cljs2, but it can also be used standalone, or be a library for other cljs test tooling
I've put a lot more work into kaocha-cljs2 the past few weeks as well, including figuring out how it'll work outside of shadow-cljs.
but it relies on https://clojure.atlassian.net/browse/CLJS-3276 which might take some time to get merged
@plexus Cool, so CLJS-3276 will allow more dynamic forms of require at compile time (e.g. using env vars etc.)?
I thought CLJS only processes top level require forms outside ns. So how does one do that?
ah yeah no you're right, if you want to generate a require statement with a macro (which may check env vars) then you need this
I'm doing something very similar to CLJS right now in babashka for creating uberscripts. But CLJS-3276 might be cool to support there as well
currently ClojureScript starts from the top of the files, if it finds an ns form it uses that, if it finds require statements it reads them until it finds some non require statement and then merges them as if it's a single ns form
(technically I think you could have requires followed by an ns, but not the other way around)
so this patch does two things, it continues reading after
ns to see if it finds require statements there, or if it finds another form it check if its a macro (based on the previous ns form), if so it loads the macro, analyzes it, and if it turns into a require it processes it
making sure the macro is able to be expanded is the most tricky part because normally loading macros happens in a later pass... I managed to work around it but waiting for David to tell me if this solution is acceptable or if he has other ideas for how to tackle it
the reason we need this is that Chui also uses a macro to inspect the compiler state and find test vars. For that to work we have to be sure that this test-finding-macro only gets compiled after all the tests have been compiled, so conceptually you need this
(ns foo (:require alll...your...tests) (:require-macros [find-tests!]))) (find-tests!)
but, we don't want to tell people to manually require their tests. That just leads to someone forgetting a test and it never being run. Shadow-cljs has provisions for this, if you use
:node-test you can give it a test ns, and it will inject the necessary requires
I've seen other solutions to create ns forms dynamically at read or compile time, but I think this one is more flexible and applicable to more than just kaocha.
(i mean, the shadow-cljs solution is good too, but not going to migrate all the non-shadow-cljs projects to shadow-cljs when i need to touch them :P)
I tried to propose adding similar functionality to the cljs compiler, but that wasn't warmly received. Instead David said "just use a macro", and I thought, "great", except that it turns out it doesn't work 🙂
I know I know... but one of the reasons for kaocha-cljs2 is that we need some way to support people using shadow. Turns out that that is actually pretty easy because shadow has good testing provisions, but now it's a lot more work to support the rest again.
but yeah David agrees that this should work so I'm sure at some point it will work, and then we can support vanilla cljs as well as figwheel, lein-cljsbuild, etc.
the core of the issue of course is that shadow is really a different compiler from all the rest, so if people use shadow then all builds have to be done by shadow. If people use figwheel then we could still do a build with cljs.main as long as we have the same compiler opts
This is kiiiind of the reason I'm still using cljs-test-runner, although you call it a POC, it works great for my purposes ;)
I mean you could use kaocha-cljs, should work just as well. cljs-test-runner is really just a wrapper around doo, which does the compile-everything-to-a-blob thing, which I dislike because it lacks observability
@plexus I've tried it but last time I tried it it didn't work with advanced compilation tests
true, it relies on a
repl-env which implies
:optimizations :none, but that's one of the use cases that kaocha-cljs2 will support
I've now worked a couple of months in this team where we maintain something like 20 services and the clojure/cljs ones just use
lein test and Doo, and it works just fine... but if I ever need watching or Doo breaks, I'll introduce Kaocha
@tavistock you can try
bin/proj install now if you want to install a local copy of
I should release this as a proper tool at some point, but some lambdaisland-specific assumptions are baked in at this point
➜ bin/proj Usage: bin/proj [COMMAND] [COMMAND_ARGS...] release Release a new version to clojars pom Generate pom files install Build and install jar(s) locally gh_actions_changelog_output Print the last stanza of the changelog in a format that GH actions understands help Show this help information inspect Show expanded opts and exit gen-readme Generate README based on a template and fill in project variables update-readme Update sections in README.md
code is here http://github.com/lambdaisland/open-source/ if you're managing multiple open source projects and you want some unified setup, or if you have projects that consist of multiple sub-projects in one repo then this might be quite useful. I was surprised at the lack of good solutions for building/releasing libraries (and not just applications/uberjars) with deps.edn
A new kaocha-cloverage is out, it just bumps cloverage to 1.2.0, which again seems to contain a bunch of fixes and improvements. Thanks @cksharma122 for doing the upgrade!
Hi @plexus 👋, i have been trying chui / kaocha-cljs2 , and it looks really promising! Thanks for the great work.
One thing that i miss most in shadow-cljs is the ability to only run a subset of tests, seems now I can do it with kaocha-cljs2!
hey that's awesome! kaocha-cljs2 is still pretty fresh but we're using it at Nextjournal and I'm actively working on it. If you find anything that bothers you let me know. Some user reports would be really helpful at this point.
I'll update the docs soon to have some better instructions on how to set things up with or without shadow
No, it's not technically possible. We have a few hooks that fire on the suite level, but most hooks fire once for the whole test run. E.g. what if you enable junit-xml for a single suite, and then run tests across multiple suites? That just doesn't make sense. Maybe explain what you're actually trying to accomplish and I can help figure out how best to do that.
Thanks for the explanation :thumbsup: What I’m trying to achieve is not run coverage while running my integration tests. Reason being I have pre-commit hook that checks for coverage threshold. which can fail for integration tests. I want to check coverage threshold only for the unit tests.
Sorry for a stupid question, but the coverage report is not having colours (everything is coming in white text on terminal) as cloverage report gives. Is there any option that I need to enable?
Hey @plexus, I am trying to migrate to kaocha-cljs2 and don’t quite see how to plug it together with
:node-test and shadow. I see there and node runner and a shadow-cljs runner but it looks like neither of those cover my specific use case
Okay looks like I am piecing it together a bit, I want to run the
Okay more piecing together. I can run some tests but those that depend on node.js libs don’t work because we are actually running in the browser
so I need to feed a node.js processes output to chui which should be running in its own process to render out the ui?