It seems to me that the discussion in #5 lead to the consensus that testitems should be organized in a tree following the same structure as the filesystem (maybe keeping the possibility to add finer tag-based subdivisions later).
This PR tries to implement this in the non-vscode context, using a tree of nested TestSets to structure the tests. For example, running the tests of TestItemRunner itself now produces the following output:
In your opinion, would that be a desirable feature ? And a correct implementation of it ?
I feel like the new TestItemTree type introduced in this PR might be useful to structure tests in the same way in the VSCode context, but I'm not sure whether this is actually the case. And if so, I'm not sure where the code could go in order to be useable in both contexts. Do you have any thoughts about this?
It seems to me that the discussion in #5 lead to the consensus that testitems should be organized in a tree following the same structure as the filesystem (maybe keeping the possibility to add finer tag-based subdivisions later).
This PR tries to implement this in the non-vscode context, using a tree of nested
TestSets
to structure the tests. For example, running the tests ofTestItemRunner
itself now produces the following output:In your opinion, would that be a desirable feature ? And a correct implementation of it ?
I feel like the new
TestItemTree
type introduced in this PR might be useful to structure tests in the same way in the VSCode context, but I'm not sure whether this is actually the case. And if so, I'm not sure where the code could go in order to be useable in both contexts. Do you have any thoughts about this?