Request Overview
Written with the help of AI; reviewed by me 😉
With cmake.ctest.testSuiteDelimiter set, tests are grouped into suite nodes in the Test
Explorer. The leaf tests get a source location — we supply DEF_SOURCE_LINE — so they show run
decorations in the editor gutter and "Go to Test" works. Suite nodes have no location, so neither
does.
Running a suite already works from the panel, so all that seems to be missing is the location: a
TestItem with a uri and range gets a gutter decoration from VS Code, and activating it goes
through the same run handler, which already expands a suite to its leaf tests via flattenTests.
So a suite would become runnable from the editor for free.
The catch is that suite nodes are synthesised by splitting test names, so there's no obvious place
for a location to come from. One idea: if a registered test's name is exactly the prefix that
would otherwise become a synthesised suite — a test named unit.GgaSentenceTests alongside
unit.GgaSentenceTests.parses_a_valid_case — use that test as the suite node, taking its
DEF_SOURCE_LINE. That needs no new property, and it would also remove the duplicate entry
reported in #4408, where such a test currently appears as a sibling of the suite instead of being
it.
Additional Information
Suite items are created without a uri today, while the leaf item just below gets one
(createTestItemAndSuiteTree in src/ctest.ts):
suiteItem = initializedTestExplorer.createTestItem(suiteId, suiteId);
...
testItem = initializedTestExplorer.createTestItem(testName, testLabel, uri);
TestItem.uri is readonly, so the location has to be known at creation time.
Worth flagging: falling back to the location of the suite's first child wouldn't help. The
decoration would land on the first test case's line instead of the suite declaration, so you'd get
two decorations on one line and still nothing on the suite. Only the suite's own line is useful.
For context we're on Boost.Test, where this maps cleanly. --list_content=DOT reports file and
line for suites as well as cases, and --run_test=<suite> runs a whole suite, so we can register
unit.GgaSentenceTests with a correct DEF_SOURCE_LINE and a working command today — it just
ends up beside the suite node rather than becoming it. Happy to test a change against a real
project.
Request Overview
Written with the help of AI; reviewed by me 😉
With
cmake.ctest.testSuiteDelimiterset, tests are grouped into suite nodes in the TestExplorer. The leaf tests get a source location — we supply
DEF_SOURCE_LINE— so they show rundecorations in the editor gutter and "Go to Test" works. Suite nodes have no location, so neither
does.
Running a suite already works from the panel, so all that seems to be missing is the location: a
TestItemwith a uri and range gets a gutter decoration from VS Code, and activating it goesthrough the same run handler, which already expands a suite to its leaf tests via
flattenTests.So a suite would become runnable from the editor for free.
The catch is that suite nodes are synthesised by splitting test names, so there's no obvious place
for a location to come from. One idea: if a registered test's name is exactly the prefix that
would otherwise become a synthesised suite — a test named
unit.GgaSentenceTestsalongsideunit.GgaSentenceTests.parses_a_valid_case— use that test as the suite node, taking itsDEF_SOURCE_LINE. That needs no new property, and it would also remove the duplicate entryreported in #4408, where such a test currently appears as a sibling of the suite instead of being
it.
Additional Information
Suite items are created without a uri today, while the leaf item just below gets one
(
createTestItemAndSuiteTreein src/ctest.ts):TestItem.uriis readonly, so the location has to be known at creation time.Worth flagging: falling back to the location of the suite's first child wouldn't help. The
decoration would land on the first test case's line instead of the suite declaration, so you'd get
two decorations on one line and still nothing on the suite. Only the suite's own line is useful.
For context we're on Boost.Test, where this maps cleanly.
--list_content=DOTreports file andline for suites as well as cases, and
--run_test=<suite>runs a whole suite, so we can registerunit.GgaSentenceTestswith a correctDEF_SOURCE_LINEand a working command today — it justends up beside the suite node rather than becoming it. Happy to test a change against a real
project.