Fork me on GitHub

Spent more time than I would like to admit with a problem I had on Kaocha-cljs. Was about to give up on Kaocha-cljs and then I found Kaocha-cljs2. Is there a reason for it being unlisted on the main Kaocha repository? Not mature enough?


I’m currently working on the cljs support across datahike deps and want to have a good automated testing story in CI. How far along is that development and the story there?


kaocha-cljs2 is still very much (pre-)alpha. It's at the point where all the main pieces are there, but you are responsible for setting up the orchestration between them. If you want to use it you should be willing to get your hands dirty and contribute to its development.


what are you using to compile your cljs?


e.g. cljs.main, figwheel, shadow? and what's your target? browser, node, something else? @grounded_sage


people that are using kaocha-cljs2 and/or chui should upgrade their funnel, the new versions has a certificate that browsers accept by default (for localhost), so you don't need the extra step of accepting the cert. (You also don't expose yourself to man in the middle attacks)


I see. It does look like a promising direction it is heading in. I currently use shadow-cljs. For now I may keep it with the shadow setup for testing. Testing on both browser and node targets. Looks like playright is going to be the successor to Puppeteer which I think we will be exploring, especially for CI if we can get that working. I will poke around a bit more if/when I have time and see how kaocha can work for us better.


shadow support is pretty much there, with the big blind spot being watch support. We need some smarts there to hook into shadow's watch cycle and that hasn't been explored yet. It's on my list though.


this repo will eventually become a set of recipes with documentation. No docs yet unfortunately but you can see some examples of how to set things up

πŸ‘ 6

main thing to note is that for :browser-test you use :runner-ns kaocha.cljs2.shadow-runner, whereas for :node-test you use :main kaocha.cljs2.shadow-runner/start, this is a bit of an inconsistency in shadow-cljs but it actually works well for us because it makes it easy to use the same namespace for both use cases (cc @royalaid)


Yes the shadow integration looked good to me so even choosing that initially there would seem to be a simple upgrade path. The elephant in the room for me is CI testing and how that will look.


yeah again that's orchestration, that's where most of the open questions are now, and I don't want to prematurely bake in specific recipes. But it's also not hard, you can do it from a shell script - start funnel in the background - run your shadow build - start a node process / headless browser tab - invoke kaocha you probably also want to background node since that won't exit automatically when the test run finishes


there are always these three parts: running the ClojureScript compiler, booting up a JavaScript runtime, invoking the test runner (and funnel needs to be around so the last two can find each other). But you can see from this that there are endless permutations. How are you compiling your cljs? shadow/lein/boot/..., optimizations, compiler settings. JS runtime... node, browser, webworker, graaljs, ... Do you want to reuse it (typical for a browser tab) or is it better/easier to start a new process? (node). If you're reusing, how does it get updated after a new compilation?


so we'll have ready-to-go recipes for the common cases, and you can use those as-is, or use them as a starting point for your own recipes. The big difference with kaocha-cljs(1) is that these are all independent. In the old kaocha-cljs we relied on the REPL env, which implied running the clojurescript compiler in a certain way, it dictated how a JS runtime would be started, what its lifetime is, etc.


"when it breaks you get to keep both pieces"


^--- I think this might become the tagline for kaocha-cljs2 πŸ˜‰

πŸ‘ 3

Yes it’s a messy environment to work on. I definitely think you are on the right track and doing very valuable work with this. This pick and choose with common recipes is the clojure way right haha. Much better for long term stability πŸ™‚


Forget what I said earlier about funnel's certificate. I think I misjudged what's possible. Going forward i think we'll no longer include a cert, and only start ssl if you provide one yourself, with instructions on how to set that up with bhauman/certifiable


@plexus I ran up against issues with watch yesterday so as a workaround I just excluded cljs file watching and manually reran the tests by pressing enter


its a little jank but it works for now


you also have to do a bit of wrangling because you need to start a regular node repl and then load the tests


and shadow doesn't have a node equiv of :browser-test that collects up all the tests and starts a repl

royalaid20:08:42 issue with Shadow here provides some context