There are a lot of tests that verify very specific details that used to exist here in the legacy-protocol -> VS Code mappings, that are now just part of LSP.
For example, there are a large number of completion tests:
https://github.com/Dart-Code/Dart-Code/blob/master/src/test/dart/providers/completion_item_provider.test.ts
Most of these are verifying things where the logic now exists in (and is tested in) the LSP server. Having all of these tests is somewhat redundant and makes the test runs slower.
We should instead just keep a few basic tests that ensure the general interaction with completion is working, and not all of the specifics about how the server maps things (these kinds of tests just fail if we do make changes to how we map things in the server).
The same is likely true for a lot of language features, and probably many debug features as a result of DAP moving to the SDKs too.
There are a lot of tests that verify very specific details that used to exist here in the legacy-protocol -> VS Code mappings, that are now just part of LSP.
For example, there are a large number of completion tests:
https://github.com/Dart-Code/Dart-Code/blob/master/src/test/dart/providers/completion_item_provider.test.ts
Most of these are verifying things where the logic now exists in (and is tested in) the LSP server. Having all of these tests is somewhat redundant and makes the test runs slower.
We should instead just keep a few basic tests that ensure the general interaction with completion is working, and not all of the specifics about how the server maps things (these kinds of tests just fail if we do make changes to how we map things in the server).
The same is likely true for a lot of language features, and probably many debug features as a result of DAP moving to the SDKs too.