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
Runnable[] tests is where it uses the test functions
"@maven//:ch_epfl_scala_bsp_testkit_2_13",
Hi, we got the following issue open in mill: com-lihaoyi/mill#1323
Mill 0.9.6 failed to add BSP test via Intellij, which was implmented by @samvel1024 in JetBrains/intellij-scala#476
[Trace - 04:06:30 AM] Received request 'buildTarget/scalaTestClasses - (3)' Params: { "targets": [ { "uri": "file:///project/directory" } ], "originId": "5dcf406b-5e73-46db-919b-aecde0891332" } [Trace - 04:06:51 AM] Sending response 'buildTarget/scalaTestClasses - (3)'. Processing request took 20545ms Result: nullHowever in https://build-server-protocol.github.io/docs/specification.html, I didn't see any definition of request
buildTarget/scalaTestClasses
But I do searched related request from https://github.com/build-server-protocol/build-server-protocol/blob/master/docs/extensions/scala.md
Does Intellij BSP implements a out-of-date spec? or BSP from build-server-protocol.github.io is out-of-date, and mill didn't implement it.
2 replies
build-server-protocol.github.io out-of-date?
HI, recently I'm interested in Learning about Scala 3, and I thought that Intellij Scala has one of best Scala IDE support, and hope to see it continue to be so. However there is some challenge in IDE integrating support for Scala 3 due to tasty format, and there are some remarks made by Pavel Fatin from Intellij Scala team, from https://youtrack.jetbrains.com/issue/SCL-19042
Pavel Fatin's remark:
So there's no way to read a .tasty file as raw data, only as a compiler tree (even if that's an implementation detail). This scheme is necessary and is originally intended for the Go To and Type Info actions (as a workaround), because .tasty files themselves don't contain all the required information, such as types of expressions of local definitions.
Using that scheme for indexing, however, is problematic because:
We have to bundle scala-compiler.jar, which is rather large.
The scala-compiler.jar depends on a specific Scala version (more that the data in a .tasty file), while we may need to parse different versions.
The compiler reads the data fully, whereas we don't need right-hand sides, private definitions, etc.
Redundant transformations: "bytes -> compiler tree -> tasty extractors -> string", whereas we need "bytes -> string".
More GC overhead (as we instantiate compiler trees in the same process).
More JVM classes to load / JIT compile.
The compiler indexes data during the reading, which we don't need (we build our own indexes).
There's no way to distinguish between "just reading .tasty" and invoking some advanced compiler logic (e.g. for type inference).
There's no way to read TASTy as a byte array, only as a file on disk, so we have to extract each .tasty file from a JAR during indexing.
The compiler sometimes requires a full classpath (which we don't even have during indexing) and throws an exception otherwise (this might be a bug though).
The TASTy Inspect API has bugs (because it's not actively used - the compiler accesses its trees directly). We report bugs but there are still plenty (you can see that in console during the indexing).
The SourceCode printer has bugs - because it's build on top of the TASTy Inspect API and is used even less (mostly for debug output). For example - SCL-19039, SCL-19088, SCL-19089, SCL-19090, etc.For the purpose of indexing, it would be better to read .tasty files directly. Note that, we don't need to reimplement the extensive TASTy Reflect capabilities for that, we don't even need to read all the trees (such as right-hand sides). However, because .tasty files don't contain textual information, this would require some effort (particularly, to convert types), but it seems to be a reasonable and necessary task, which will make indexing simpler, more reliable, and more fast.
//===========================================================
I wonder if there is clear official direction to add tasty support into IDE , rather keep reinventing the wheel.