-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Add more detailed Scala Test Classes Request #296
Comments
I think this is a great idea. I think Intellij could also benefit from that information, no? CC @jastice |
This proposal makes perfect sense to me. In term of implementation I would suggest a slightly different format:
First because I think it is more simple to have one layer ( More importantly it maintains the compatibility: Newer BSP servers can respond to older clients with this format and newer clients can read this format from older servers. |
Yeah, maintaining compatibility might be easier to handle on both sides, client and server, than a brand new endpoint. Thanks @adpi2! |
…1695) Build client can use information about the test framework of tests to provide better UX when running/debugging tests. More information can be found at build-server-protocol/build-server-protocol#296 (comment).
It is an implementation of the BSP proposal which is described in build-server-protocol/build-server-protocol#296 (comment). This proposal adds an optional framework field to the returned class. There's already implementation for bloop: scalacenter/bloop#1695 Also added `debugSessionStart` endpoint. Pull request: #1755
closed via #300 |
Proposition
Currently, mentioned request returns
and I want to focus on
ScalaTestClassesItem.classes
. It consists of fully qualified names, there is no additional information about e.g. test framework to which the given test class belongs. It's fine until BSP client uses other BSP endpoints to execute test such as test request or debug request. However performing some action which requires knowledge about test framework by BSP client is very challenging - client has to somehow determine test framework of the given test class.In order to solve that issue, aforementioned request can be slightly altered in order to contain such information:
Since most (if not even all) known to me BSP servers uses
sbt-test-interface
under the hood it is reasonable to define value ofScalaTestFrameworkSuites.framework
field to be the value ofFramework.name
. Then BSP Client can perform some framework-specific logic based on this field value.Motivation
Metals and test explorer are concrete example of how knowing test framewor could be used:
@Test
annotations for junit. Different strategy has to be applied for each framework.Implementation difficulty
I've looked at bloop, sbt and mill to estimate if this endpoint can be implemented in each of them - it's doable and it seems to not be difficult. I've even implemented this endpoint for bloop already as a PoC.
The text was updated successfully, but these errors were encountered: