I’ll admit professionally I’ve been out of the JVM ecosystem for a number of years now, and so not as much in the know as I use to be.
One headwind I have for continued feature development of my plugin is that the the overhead of running even 1 test is about 30 seconds. I’m not sure if this is normal.
Running with a gradle build scan suggests that it it took ~30 seconds:
30 seconds:
- 7 seconds initialization & configuration
- 22.27 seconds for Execution
- 21.951 seconds for the :test stage
I tried running the test with profiling enabled, but looking at the timeline it only caught about 3 seconds so likely attaches to late.
My project Systemd Unit File Plugin is admittedly pretty old in terms of convention, and I haven’t really modernized it.
I don’t know what other peoples experiences are, but I was curious if:
- This is about what I would/should expect?
- Anyone had any tips on what to look at.
I’m curious about the missing 19 seconds, for reference the machine I’m working on is an i9-13950HX with 128 GB of RAM.
As a first general step, try updating all tooling and plugins to their latest versions.
E.g. Gradle version 8.10 vs current 8.13 systemdUnitFilePlugin/gradle/wrapper/gradle-wrapper.properties at 242.x · SJrX/systemdUnitFilePlugin · GitHub
Unfortunately, there’s also a known issue within the IntelliJ Platform Gradle Plugin.
We rely on the IntelliJ Plugin Verifier’s structure libraries to read information about the currently targeted IntelliJ Platform and its bundled plugins, causing noticeable delays at the test/build startups.
@robert.novotny is aware and working hard to optimize that—this is our top priority now and should be resolved this month.
2 Likes
I’m also developing a plugin. My plugin displays a new tool window, and I have only found a way to test that using the integration test approach.
I find that my inner dev loop is very slow and clunky as well. For now, it seems like 5-10 minutes between each run because I’m trying to take the feedback, learn how to write the code for my IT to make the ide do what I want, and then run again.
The docs for integration testing are fairly limited and lack a substantial suite of examples and explanations. I’ve been hunting round in the Driver class, and trying to learn how to make it happen.
I wish there were a dynamic notebook that I could use to send commands from my dev ide to the ide under test, rather than a restart every time.