I have an extension which adds text decorations at the end of some of the lines. I'd like to write a test which verifies that the text decorations are added and also to assert in the test that their value is correct.
suite('Extension Tests', () => {
test('Should work', async() => {
const fixturePath = path.join(__dirname, '..', '..', 'test', 'fixtures');
const uri = vscode.Uri.file(path.join(fixturePath, 'a.js'));
const document = await vscode.workspace.openTextDocument(uri);
await vscode.window.showTextDocument(document);
window.activeTextEditor.getDecorations(); //???
});
});
It seems that the getDecorations API is missing from editor. What can I do to resolve this?
As of VSCode 1.37.1 (2019-08-30), the answer is no, there is no way to write an automated test for decorations using the decorations extensions API.
There are automated tests of decorations in the vscode sources, particularly modelDecorations.test.ts, but they use private APIs.
Microsoft has an example extension that uses decorators, decorator-sample, but it has no tests.
There are a few open issues related to this, although none directly addresses the inability to enumerate existing decorations:
50346: Lacking decorations-related APIs (mainly about incremental update for better performance); closed as duplicate of:
585: Provide an API for advanced/semantic source highlighting
50415: Missing API for knowing when an extension's decorations get trashed
54938: Make decoration provider API public
Therefore I recommend filing a new issue.
2022-04-27: As noted in a comment, issue 136164: Provide Access to a TextEditors Decorations for Testing Purposes was filed on 2021-10-30. It was then closed as unnecessary because you can test that your extension calls the extension API as intended. I find this response inadequate because there's no way to test that the effect is as intended (for example, TextEditor.setDecorations removes existing decorations that have the same type, and that's a subtle interaction that would only be revealed by examining the effects), but the issue is locked so yet another issue would have to be filed to raise an objection.
Related
I am working on a VsCode extension in that I want to provide custom snippets for code completion.
I know about the option of using snippet json files directly, however those have the limitation of not being able to utilize the CompletionItemKind property that determines the icon next to the completion suggestion in the pop-up.
My issue:
If I implement a simple CompletionItemProvider like this:
context.subscriptions.push(
vscode.languages.registerCompletionItemProvider(
{scheme:"file",language:"MyLang"},
{
provideCompletionItems(document: vscode.TextDocument, position: vscode.Position) {
let item = new vscode.CompletionItem('test');
item.documentation = 'my test function';
item.kind = vscode.CompletionItemKind.Function;
return [item];
}
}
)
)
then the original VsCode IntelliSense text suggestions are not shown anymore, only my own. Should I just return a kind of an empty response, like
provideCompletionItems(document: vscode.TextDocument, position: vscode.Position) {
return [null|[]|undefined];
}
the suggestions appear again as they should. It seems to me that instead of merging the results of the built-in IntelliSense and my own provider, the built-in ones get simply overridden.
Question:
How can I keep the built-in IntelliSense suggestions while applying my own CompletionItems?
VsCode Version: v1.68.1 Ubuntu
I seem to have found the answer for my problem, so I will answer my question.
Multiple providers can be registered for a language. In that case providers are sorted
by their {#link languages.match score} and groups of equal score are sequentially asked for
completion items. The process stops when one or many providers of a group return a
result.
My provider seems to provide results that are just higher scored than those of IntelliSense.
Since I didn't provide any trigger characters, my CompletionItems were comteping directly with the words found by the built-in system by every single pressed key and won.My solution is to simply parse and register the words in my TextDocument myself and extend my provider results by them. I could probably just as well create and register a new CompletionItemProvider for them if I wanted to, however I decided to have a different structure for my project.
In my VS Code extension I have some code that uses the built in Markdown extension. I capture a reference to it by registering as a markdown plugin and putting the following code at the end of my extension's activate method.
return {
extendMarkdownIt(mdparam: any) {
return md = mdparam;
}
};
Markdown calls this when it activates.
Generally this is not a problem. Most of the use cases for my extension involve a markdown file already loaded into the active editor, and the loading of this file triggers activation of the markdown extension.
However there are some legitimate use cases in which this is not so.
I need to programmatically trigger activation of the markdown extension. Some of these cases involve having a different kind of file open in the active editor so loading a markdown file into it is not an acceptable option.
Some potential strategies:
Change the language mode. There is a command workbench.action.editor.changeLanguageMode but no documentation. I tried
vscode.commands.executeCommand('workbench.action.editor.changeLanguageMode', 'md');
but this triggers the UI
so I tried a pattern I've seen in the parameters of other commands and added , true. This suppressed the UI but doesn't seem to work.
Load a markdown file into a new editor then close it again. This should work, but it's ugly.
Put something in the contributions section of my extension that changes the activation trigger for the markdown extension so that it is triggered by the other file types on which my extension operates.
Of these options my favourite would be 3 but I don't even know whether this is even possible. Option 1 is hampered by the crappy (in many cases non-existent) documentation for vscode internal commands.
Option 1 it is. If anyone knows how to do option 3 please tell, the solution below is a ghastly hack.
It is possible to trigger activation of the Markdown extension by changing the document language of any open editor to markdown. In the event that there are no open editors a document with the markdown language set can be created in memory and loaded into an editor.
If VS Code is busy loading extensions activation can take several hundred milliseconds so the best thing to do is watch the variable into which markdown-it is captured.
The variable md is a global (global to my extension, not the whole of VS Code) into which a reference is acquired as shown in the question.
let ed = vscode.window.activeTextEditor;
if (ed) {
let lid = ed.document.languageId;
if (lid !== "markdown") {
vscode.languages.setTextDocumentLanguage(ed.document, "markdown").then(
function waitForMd() {
if (md) {
vscode.languages.setTextDocumentLanguage(ed!.document, lid);
} else {
setTimeout(waitForMd, 100);
}
}
);
}
} else {
vscode.workspace.openTextDocument({ language: "markdown" }).then(doc => {
vscode.window.showTextDocument(doc).then(
function waitForMd() {
if (md) {
vscode.commands.executeCommand("workbench.action.closeActiveEditor");
} else {
setTimeout(waitForMd, 100);
}
});
});
}
Once the capture completes we can restore the true language or close the editor as appropriate. To be realistic the second case (no active editor) is unlikely because my own extension won't activate until you load something. At any rate it works stably now. The larger project is progressing nicely.
I love testing-library, have used it a lot in a React project, and I'm trying to use it in an Angular project now - but I've always struggled with the enormous error output, including the HTML text of the render. Not only is this not usually helpful (I couldn't find an element, here's the HTML where it isn't); but it gets truncated, often before the interesting line if you're running in debug mode.
I simply added it as a library alongside the standard Angular Karma+Jasmine setup.
I'm sure you could say the components I'm testing are too large if the HTML output causes my console window to spool for ages, but I have a lot of integration tests in Protractor, and they are SO SLOW :(.
I would say the best solution would be to use the configure method and pass a custom function for getElementError which does what you want.
You can read about configuration here: https://testing-library.com/docs/dom-testing-library/api-configuration
An example of this might look like:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
You can then put this in any single test file or use Jest's setupFiles or setupFilesAfterEnv config options to have it run globally.
I am assuming you running jest with rtl in your project.
I personally wouldn't turn it off as it's there to help us, but everyone has a way so if you have your reasons, then fair enough.
1. If you want to disable errors for a specific test, you can mock the console.error.
it('disable error example', () => {
const errorObject = console.error; //store the state of the object
console.error = jest.fn(); // mock the object
// code
//assertion (expect)
console.error = errorObject; // assign it back so you can use it in the next test
});
2. If you want to silence it for all the test, you could use the jest --silent CLI option. Check the docs
The above might even disable the DOM printing that is done by rtl, I am not sure as I haven't tried this, but if you look at the docs I linked, it says
"Prevent tests from printing messages through the console."
Now you almost certainly have everything disabled except the DOM recommendations if the above doesn't work. On that case you might look into react-testing-library's source code and find out what is used for those print statements. Is it a console.log? is it a console.warn? When you got that, just mock it out like option 1 above.
UPDATE
After some digging, I found out that all testing-library DOM printing is built on prettyDOM();
While prettyDOM() can't be disabled you can limit the number of lines to 0, and that would just give you the error message and three dots ... below the message.
Here is an example printout, I messed around with:
TestingLibraryElementError: Unable to find an element with the text: Hello ther. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.
...
All you need to do is to pass in an environment variable before executing your test suite, so for example with an npm script it would look like:
DEBUG_PRINT_LIMIT=0 npm run test
Here is the doc
UPDATE 2:
As per the OP's FR on github this can also be achieved without injecting in a global variable to limit the PrettyDOM line output (in case if it's used elsewhere). The getElementError config option need to be changed:
dom-testing-library/src/config.js
// called when getBy* queries fail. (message, container) => Error
getElementError(message, container) {
const error = new Error(
[message, prettyDOM(container)].filter(Boolean).join('\n\n'),
)
error.name = 'TestingLibraryElementError'
return error
},
The callstack can also be removed
You can change how the message is built by setting the DOM testing library message building function with config. In my Angular project I added this to test.js:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
This was answered here: https://github.com/testing-library/dom-testing-library/issues/773 by https://github.com/wyze.
I have used the tokenizer in monaco but I do not see that it is accessible in vscode. This would be helpful for completion/signature help providers, how can I tokenize a grammar?
It doesn't seem like there's an official way of doing this right now. There is an open feature request for adding the ability to retrieve tmLanguage scopes at a position here: #580
There is one potential workaround, which requires adding a dependency to the scope-info extension. This extension exposes an API of its own that other extension can use. Here's a code example posted by the author in the linked issue:
import * as api from 'scope-info'
async function example(doc : vscode.TextDocument, pos: vscode.Position) {
const siExt = vscode.extensions.getExtension<api.ScopeInfoAPI>('siegebell.scope-info');
const si = await siExt.activate();
const t1 : api.Token = si.getScopeAt(doc, pos);
}
Update: unfortunately, it looks like scope-info is no longer compatible with current VSCode versions.
I have used the tokenizer in monaco but I do not see that it is accessible in vscode. This would be helpful for completion/signature help providers, how can I tokenize a grammar?
It doesn't seem like there's an official way of doing this right now. There is an open feature request for adding the ability to retrieve tmLanguage scopes at a position here: #580
There is one potential workaround, which requires adding a dependency to the scope-info extension. This extension exposes an API of its own that other extension can use. Here's a code example posted by the author in the linked issue:
import * as api from 'scope-info'
async function example(doc : vscode.TextDocument, pos: vscode.Position) {
const siExt = vscode.extensions.getExtension<api.ScopeInfoAPI>('siegebell.scope-info');
const si = await siExt.activate();
const t1 : api.Token = si.getScopeAt(doc, pos);
}
Update: unfortunately, it looks like scope-info is no longer compatible with current VSCode versions.