jvmRunEnvironment, which was a follow up of our discussions on jvmRunEnvironment when we decided, we want to have these two environment endpoints separate. In case if you'd like to merge them to a sigle jvmEnvironment instead, please just let me know.
Hey folks, so I'm looking at https://github.com/build-server-protocol/build-server-protocol/blob/master/docs/specification.md#test-request
I'm maintaining a (niche) test framework and find myself having to implement an Intellij plugin to satisfy some users that really really want to run tests by clicking on buttons. A coworker and myself have come up with a hacky way for intellij to detect individual tests, which works short term but feels crap (ie I'd rather not do that for every single ide/editor)
Is there some sort of test-framework agnostic piece of the protocol for test discovery ? IE, currently metals lets me run test suites from the editor, I assume by tapping directly into https://github.com/sbt/test-interface to detect what is a suite. Would it make sense for BSP to contain semantics for the test framework to return test names/locations to the editor, for it to display relevant UI elements ?
@RunWith(...) annotation then IntelliJ will automatically pick it up
Filterable interface from JUnit then users can optionally edit the IntelliJ configurations to select individual tests. It won't give you "go to test case definition", but it's better than nothing. See the MUnit runner https://github.com/scalameta/munit/blob/0c4ff57f667970e6574a4c7e02a6296e9feb8990/munit/shared/src/main/scala/munit/MUnitRunner.scala#L30
:+1: this all makes sense, and confirms my suspicions.
if your goal is to have a nice GUI to run tests via IntelliJ then I am afraid the best (and only?) solution is to write a custom IntelliJ plugin.
depends. short term goal is what you describe. But it definitely feels like there should be some kind of protocol to describe these sort of interactions between the IDE and the test framework