Expose rename provider's prepareRename functionality for testing

[DanTup]

In #7340 new functionality was added to resolve renames to ranges with placeholder text, however it doesn't seem to be available in tests (unless you have a reference to the provider). vscode.executeDocumentRenameProvider calls the provideRenameEdits method but not the prepareRename method.

[jrieken]

unless you have a reference to the provider)

What's so bad about that? The information from prepare isn't fed into the provideRenameEdits anyways so I might be missing what the problem is?

[DanTup]

I can't easily get a reference to my rename provider without exporting it in my extension (and it feels weird to just start exporting everything in my extensions "API"). I thought the expected way to test providers was through the commands (though I may be mistaken).

[jrieken]

I thought the expected way to test providers was through the commands (though I may be mistaken).

Well, that might work but that isn't the design goal. Not quite sure why you would need to export the provider via your API? Can't you simply create a new/different instance of the provider in your unit test?

[DanTup]

@jrieken I'm trying to write full end-to-end tests; it'd be really easy to write passing unit tests and have broken functionality (because the interesting things are generally the interactions between Code and my code of my code and the language server... or for example if I didn't register my provider correctly!). My tests are often like:

1. Write a known set of code into the editor
2. Invoke some command at a specific location
3. Check the new code in the editor

This makes sure my understanding of both Code and the language server's APIs are sound (there are many complications that'd be hard to unit test, like 0-based and 1-based offsets, multi-cursor edits, document being modified during an async operation, etc.).

I understand if you don't think adding commands for everything is the right thing to do, but I do think supporting end-to-end testing like this is really valuable.

[jrieken]

Yes, I understand the concept of higher-level tests but I don't agree that because of that everything should be exposed/accessible via the API. So, for this specific example, please use a unit-test.

[vscodebot]

We have a great developer community over on slack where extension authors help each other. This is a great place for you to ask questions and find support.

Happy Coding!

[DanTup]

Understood. For now I think exposing the provider in my exports would be better; creating unit tests doesn't feel all that worthwhile (I'd have to mock the language server, and then I wouldn't actually be testing the thing I care about - the interaction with the language server).