Closed sgraband closed 10 months ago
Would be nice to have, e.g. for integrating https://github.com/robocorp/robotframework-lsp with Test Explorer view in Theia.
Note that the test API has been stubbed for now. So extensions using this API aren't blocked from running, but usages of the test API won't have any effect.
Hello, I speak on behalf of the student project team from Polytechnique Montreal (Kevin, Théo, Mathieu and Zakaria). This is our first time contributing and we would like to work on this API. We are still going through some tutorials and documentation to make sure we understand how to implement this feature (we might have a slow start).
Here is what we are doing right now in order to understand how to implement the Test API:
Question:
Are we missing something? Is there some documentation or examples we should read?
Hi, are the test coverage and observer part not to be considered in the implementation based on this issue as the functions like runTests
, createTestObserver
and onDidChangeTestResults
that are part of the tests namespace and the different variables and fields that come along were not included in the description and the stubbed tests API
Hi, are the test coverage and observer part not to be considered in the implementation based on this issue as the functions like
runTests
,createTestObserver
andonDidChangeTestResults
that are part of the tests namespace and the different variables and fields that come along were not included in the description and the stubbed tests API
@sgraband
The functions you are listed are part of vscodes proposed api. If i rememeber correctly proposed api is not required to be compatible. @planger is this correct?
Hi, are the test coverage and observer part not to be considered in the implementation based on this issue as the functions like
runTests
,createTestObserver
andonDidChangeTestResults
that are part of the tests namespace and the different variables and fields that come along were not included in the description and the stubbed tests API
We talked about this in today's DevMeeting. From what I understood, if the Test API doesn't make heavy use of the proposed API, then there is no need to implement it.
I wanted to add some information of something that we found during the last month. There are some UI implementation to be done to make this API complete. There is something called testingDecoration
that are the little play buttons that should appear in the editor's gutter when a test is detected. Here is more information on the UI implementations:
common
folder: https://github.com/microsoft/vscode/blob/1.72.2/src/vs/workbench/contrib/testing/common/testingDecorations.tsbrowser
folder : https://github.com/microsoft/vscode/tree/1.72.2/src/vs/workbench/contrib/testing/browser When we first looked at this issue we didn't think there was any UI implementation to be migrated. Is this part of the issue?
I wanted to add some information of something that we found during the last month. There are some UI implementation to be done to make this API complete. There is something called
testingDecoration
that are the little play buttons that should appear in the editor's gutter when a test is detected. Here is more information on the UI implementations:* testingDecoration in the `common` folder: https://github.com/microsoft/vscode/blob/1.72.2/src/vs/workbench/contrib/testing/common/testingDecorations.ts * Some more files on the UI implementation in the `browser` folder : https://github.com/microsoft/vscode/tree/1.72.2/src/vs/workbench/contrib/testing/browser * Video showing a example of what it should look like: https://youtu.be/AulgIP9P8Cw?t=60
When we first looked at this issue we didn't think there was any UI implementation to be migrated. Is this part of the issue?
We discussed this in a Dev Meeting and the answer is yes. The UI must be migrated as well.
@JonasHelming @D-Zaq @mathblin @paul-marechal @colin-grant-work @MatthewKhouzam @tsmaeder Here is a condensed report of known issues and what is/isn't implemented in the current PR :
Known issues:
Implemented:
packages/testing/src/common
folder with the code necessary for Plugin Host (contains a lot of code necessary for Main Browser as well) vscode/src/vs/workbench/contrib/testing/common
vscode/src/vs/base/common
vscode/src/vs/editor/core
tests.ts
implemented at run-time in function TestingExtImpl::createTestController
)test-items.ts
as TestItemImpl
) types-impl.ts
)tests.ts
as TestRunProfileImpl
) types-impl.ts
) test.ts
)ExtHostTesting.ts
in vscode)
ExtHostTesting
from vscode now called TestingExtImpl
Note: The following diagram shows the files that were added or modified to make Plugin Host work:
constants.ts
, we can look at its parent nodes common
in light blue, testing/src
in orange and theia/packages
in dark blue and know the file constants.ts
is found in the path theia/packages/testing/src/common/constants.ts
draw.io file: migrated-and-changed-files.zip
Not implemented:
Note: The following diagram shows the files from VS Code that we think should be imported for the Main Browser and UI to work (other files might be missing) :
draw.io file: files-to-migrate.zip
Feel free to ask any questions about the report or the code before the next meeting on May 2th. That way we will be able to answer them in more detail at the meeting.
Here is a simple extension that pokes the functions createTestController
, createRunProfile
, createTestItem
and createTestRun
of the Test API. It returns a notification for each of the functions with "SUCCESS" or "FAIL" with details if the functions throw an error.
vsix file: test-api-functional-test-0.0.2.zip Source code: https://github.com/KevinClapperton/Test-API-functional-test
Once the extension is installed in Theia, execute the command Test API: Run All Test
in the command palette to call the Test API functions.
I'm thinking about what UI we would have to have to implement this API:
In a first step, we could leave out the marker support, since that duplicates functionality from the Test Explorer view. The "peek error" support in VS Code could maybe be replaced by a hover on failed tests. We could also kind of ignore "continuous run" capabilities by always requesting "continuous=false" when running tests. Any "proposed" functionality like coverage or TestObserver could be safely stubbed.
So a preliminary plan might be:
Some further notes...
TestItem
instances, and you would think from the API that you can manipulate these, but in fact, they are effectively readonly. That makes sense, since an extension cannot be expected to run a test it did not create through its controller.Note that propagating test run results is also something that might happen at a fast pace an profit from batching. We have to keep in mind that we might have to match a particular result to the location in the test item tree and design data structures accordingly.
Feature Description:
Add function from the
tests
namespace:Add required variables, functions and fields from
root
namespace:VSCode API for reference: https://code.visualstudio.com/api/references/vscode-api#tests.