Clojurians Log v2

Just checking - is anyone using the new test runner stuff? Is it working ok? I’ve only had one bit of feedback that a simple test worked, so that means either it’s all working fine or no-one is using it 🙂. If it’s working I’ll get a stable build out soon so users upgrading to 2020.3 aren’t bitten by the namespace navigation bug.

@cfleming I tested it briefly. My rather big application takes north of 30 seconds to start. My usual workflow is to run the tests in a repl (with “Run Tests in Current NS in REPL” and friends bound to custom key combinations). Since the new test runner spins up a new instance of the app it just takes too long. Admittedly I should address the underlying problem, but there is always going to be some startup cost that is greater than just running the tests in a repl.

Thanks for the feedback. But I assume that if you do “lein run” or whatever then it takes the same amount of time, right? i.e. it’s not actually a problem with the runner itself.

One thing I had thought of was allowing the run config to execute in the active REPL instead of opening up a new process, but that’s unfortunately hard because the IntelliJ testing stuff is very tied to starting a process. But that might not be impossible if there’s interest.

I start the process with lein repl in the terminal, then I connect using a “Remote REPL” run configuration. This way my application process lifetime is not tied to IntelliJ. The test runs are instantaneous when run this way.

Hm, I’m trying out different stuff now. Seems I can’t edit the Leiningen run configuration now. The window’s just empty.

I’ll post a screenshot in a sec…

A question about protocols: Is it (or rather, should it be) possible to find implementations of protocols using Option-Command-B (Navigate -> Implementation(s))?

@cfleming I also gave it a brief try just now and it seems to be working well. However my workflow is also repl-focused. I'd load the project, start the repl inside idea and work and run tests within the repl connection. For CI we use the kaocha test runner so before pushing I'd run that from the command line. I also have repl commands to run kaocha in-repl. Integrating kaocha with idea would be interesting to me as we use its plugin system etc so the tests being run through kaocha are different to what Cursive's built-in test runners discover

It definitely works for me, but I’m not at the point to include it in my workflow. I normally use the REPL so that the liquibase DB changes don’t have to be run every time I run the tests, they only have to run the first time. I have some ideas on making it a bit better, however it generally works so it’s good enough to :shipit: There are some neat things that it looks like are included in this, so I can see this tool continuing to grow in the future and being really great for sure.

I'm not entirely sure how to integrate the test runner stuff into my workflow. Maybe I'm missing something. We already have a flow set up to run tests (kaocha) on CI. When running tests, it seems best to run them in the same manner that they'd run on CI. During development, I almost always have a REPL open and will run my tests using one of the REPL shortcuts. Running a test or tests in a fresh JVM takes a long time -- the initial boot up can be like 30-40s for a large application.

The one piece that did seem useful for certain scenarios was the ability to run a test using the cpu profiler or java flight recorder.

@msolli Could you send me your log file, please? Help | Show log in Finder

Thanks for the feedback everyone, I agree that the REPL workflow is the most useful for development. I mostly use the full test suite as a sanity check for not having broken anything after making changes, although CI should pick those up too.

I’ll check the CPU profiler thing too.

I’m also hoping to integrate coverage information which would be useful.

@cfleming for sure! I think there are going to be some really cool enhancements coming out of this

as i mentioned before, the test runner feature might be more appealing to those who come to clojure from other languages where the only way to run tests is via a fresh jvm (java, scala, etc.) during the transition period (maybe). i myself run my tests using kaocha with its --watch feature in a terminal these days... so... if this test runner one day can do just that, i.e., running tests reusing the same jvm upon changes to files (the --watch feature), i can totally see myself switching to it. i think intellij idea already supports this for running jest tests within the ide: https://www.jetbrains.com/help/idea/running-unit-tests-on-jest.html#createRunConfigJest

Interesting, thanks - back in the day I asked JetBrains about that and their runner didn’t support it. I guess they’ve added that in a recent version, I’ll ask about it again.