Add `DebugSessionParamsDataKind` which will allow finer granulation of tests.

Debug request has field data which content depends on dataKind. Currently, there is only one possibility to run/debug tests and it is SCALA_TEST_SUITES kind. https://github.com/build-server-protocol/build-server-protocol/blob/2db6bd5093052058368c5390cfbbdcad4095bb4b/bsp4j/src/main/java/ch/epfl/scala/bsp4j/DebugSessionParamsDataKind.java#L5

However, for this kind, the data field is an array of strings, for example ["a.b.myTestSuite, "a.b.c.AnotherTestSuite"], which is a very coarse granulation. A single test suite could consist of multiple test cases and it is impossible to represent a test run that consists of single or multiple (but not all) test cases from a particular test suite.

That’s why I’d like to propose another DebugSessionParamsDataKind - (it’s just a working name) SCALA_TEST_CASES. data for this kind can look like TestCases[], where TestCases is defined as

interface TestCases {
  suiteName: string,
  tests: string[]
}

Assuming that ["a.b.myTestSuite, "a.b.c.AnotherTestSuite"] are test classes in project, such data structure will allow to represent:

• run for single test within single test suite- [{suiteName: a.b.myTestSuite, tests: ["test 1"]}]
• run for multiple test within single test suite - [{suiteName: a.b.myTestSuite, tests: ["test 1", "test 3"]}] // “test 2” is omitted
• run for multiple tests within multiple test suites - [{suiteName: a.b.myTestSuite, tests: ["test 1"]}, {suiteName: a.b.c.AnotherTestSuite, tests: ["test 15"]}]

suiteName together with the values of tests can be used to construct test selector which can be further used to filter out unwanted test cases.

This proposition is based on my experience gained in https://github.com/scalameta/metals/pull/3277. Over the next days/weeks I’ll try to do some more research or maybe even small proof of concept that will confirm if the proposed interface is sufficient, but I think it’s a good time to open the issue and gather others’ feedback about this.

[adpi2]

That would be great.

Also if we change the format of the debug test request we should also add the jvm options (and environment variable) , as was suggested here and here.

A possible format would be:

export interface ScalaTestSelection {
  /** The build target that contains the test classes. */
  target: BuildTargetIdentifier;

  /** The jvm options for the application. */
  jvmOptions: String[];

  /** The environment variables for the application. */
  environmentVariables?: String[];

  /** The fully qualified names of the test classes in this target and the tests in this test classes */
  classes: ScalaTestSuiteSelection[];
}

where ScalaTestSuiteSelection could be:

export interface ScalaTestSuiteSelection {
  /** The test class to run. */
  class: String;

  /** The selected tests to run. */
  tests: String[];
}

Also I think we should have a convention that tests= [] means all the tests.

[kpodsiad]

closed via https://github.com/build-server-protocol/build-server-protocol/pull/304