Fork me on GitHub

hello @plexus - i hope you're doing well today 🙂 we use bultitude to find namespaces for a specific sub-system. on java 8, our tests for this code work fine. however, on java 11, bultitude seems to have lost access to all the files in the src folder, when running the tests via kaocha. i've done some digging, and i've been able to confirm that the code in the deps.edn profile in the test folder works fine outside of the kaocha runner. i've even altered the kaocha config to force src into the test-paths, with no joy. does any of this trigger a known gotcha that i might be able to look into for you?


We do some funny shenanigans to dynamically add :test-paths to the classpath. Maybe that's getting in your way?


thanks i'll read!


if that's the culprit then I think we can add a flag to disable that and let people manage their own classpath


i'm pretty sure this is the cause, but i couldn't tell you why specifically - what i see from inside the K run is that only ./test is on the CP and ./src is not. is it perhaps possible there's a java 11 bug in dynapath?


given that it's mucking with classpaths directly


thanks for the quick response btw ^_^


definitely not impossible. I'm not familiar with bultitude but it may also depend on how it figures out the classpath. Does it only look at the current context classloader, or does it follow the chain of classloaders?


pretty sure its just the former


classpath is a bit of a murky concept 🙂 more than one way to determine what "the classpath" is


oh man i feel like i am looking over the edge into a deep dark hole here haha


yeah so that's likely what's happening here. Not all classloaders are modifiable, so to be able to modify the classpath we add a new clojure.lang.DynamicClassLoader to the top of the chain


mostly got this working through trial and error, I'm also no export in these JVM specifics. I'm more surprised that it's taken this long before this caused an issue for someone.


my guess is you had to do this to insulate from the different tool contexts - lein/deps/boot?


selfishly, it'd be great if, for our deps case, it just used whatever deps gave it


given that, it sounds like your suggestion of an opt-out flag is the right way to go then


the idea was mainly that you wouldn't have to configure your test paths twice, since we do need to know what your test paths are e.g for --watch or for code coverage


but yeah in practice generally people already have their test paths in their deps.edn or whatever anyway, e.g. for REPL driven dev


thanks for taking the time to talk @plexus 🙂


@robert-stuttaford try {lambdaisland/kaocha {:mvn/version "1.0.632"}}, and add :kaocha.testable/skip-add-classpath? true to the test suite config (so not the top level config but at the same level where you have :test-paths)


ok wow that's awesome i'll try that! thank you sir


it's a one line change but I will admit I did not actually test it. Testing in production like a pro 💪:skin-tone-2:


haha all good, i'll try it out


In java 11, can no longer reflect against the base classloader.


I've pushed a lot of improvements to Chui today, and highly encourage people to try it

🔨 8
🎉 4

Assuming you are using shadow-cljs and :target :browser-test


We'll eventually figure out instructions for figwheel and cljs.main, but to provide the same experience we'll need some extra functionality in figwheel or clojurescript to detect test namespaces and inject them into the build.


with many thanks to @anantpaatra for his great work on the UI design

😅 4
👏 4

Feedbacks on the UI are appreciated as well!

Drew Verlee21:05:21

Is there something i need to do in order to enable Expound output when running tests? i'm executing the normal -m "kaocha.runner" i see expound alluded to in the docs and could but not how to enable it. i'm too tired to read raw spec errors all day 🙂