Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submit tests for intellisense (replacing functional tests we had) #7565

Merged
merged 37 commits into from
Sep 22, 2021

Conversation

rchiodo
Copy link
Contributor

@rchiodo rchiodo commented Sep 16, 2021

For #7028

I worked on this a week ago and was waiting on the python extension to submit changes I made. They should be there in the python insiders bits.

However I also want these tests in place for the work I'm doing to move intellisense to the jupyter extension. Once these are in, I'll make changes/add to them to test the work I'm doing to create a language server per interpreter.

@rchiodo rchiodo requested a review from a team as a code owner September 16, 2021 19:33
@codecov-commenter
Copy link

codecov-commenter commented Sep 16, 2021

Codecov Report

Merging #7565 (e3ef4a7) into main (ddda5fa) will increase coverage by 2%.
The diff coverage is 86%.

@@          Coverage Diff           @@
##            main   #7565    +/-   ##
======================================
+ Coverage     66%     68%    +2%     
======================================
  Files        365     364     -1     
  Lines      22659   22555   -104     
  Branches    3444    3429    -15     
======================================
+ Hits       15115   15497   +382     
+ Misses      6260    5733   -527     
- Partials    1284    1325    +41     
Impacted Files Coverage Δ
...atascience/interactive-window/interactiveWindow.ts 54% <ø> (-1%) ⬇️
src/client/datascience/notebook/types.ts 100% <ø> (ø)
...cience/notebook/intellisense/completionProvider.ts 61% <66%> (+7%) ⬆️
.../datascience/notebook/notebookControllerManager.ts 84% <80%> (-1%) ⬇️
src/client/datascience/constants.ts 99% <100%> (+<1%) ⬆️
src/client/datascience/jupyter/jupyterNotebook.ts 25% <100%> (+<1%) ⬆️
...t/datascience/notebook/vscodeNotebookController.ts 77% <100%> (-3%) ⬇️
...ient/datascience/jupyter/kernels/kernelSelector.ts 57% <0%> (-24%) ⬇️
...ience/notebook/emptyNotebookCellLanguageService.ts 72% <0%> (-4%) ⬇️
...rc/client/datascience/notebookStorage/baseModel.ts 70% <0%> (-4%) ⬇️
... and 42 more

return [];
} else {
traceInfoIf(isCI, `Completions found, filtering the list: ${JSON.stringify(result)}.`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should just turn this into traceIfCI, lol, feels kinda redundant to always pass in isCI. What do you think.
We might have a few places where we'd have some other conditions being passed in, but i think traceIfCIortraceOnCI` is simpler.
Absolutely no need to make that change, just a thought

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sounds like a good idea. I'll add a debt issue

assert.ok(diagnostics.find((item) => item.message.includes('system')));
});
test('Markdown cells dont get errors', async () => {
// Create two cells, one markdown, make sure not diagnostics in markdown
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

@rchiodo
Copy link
Contributor Author

rchiodo commented Sep 21, 2021

@IanMatthewHuff and @DonJayamanne can you take a second look?

I reworked how we select a kernel in the tests. It now loops on the notebook.selectKernel function. But the default it picks is lot more complicated now. Actually found a bug with this change: #7610

I also reworked how variables are waited for in tests. Instead of guessing the messages to be sent, I switched it to just use waitForCondition which should work regardless of how many messages get passed around.

await this.setAsActiveControllerForTests(notebook);

// Keep track of if this controller is preferred for this notebook
if (affinity === NotebookControllerAffinity.Preferred) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updateNotebookAffinity is called on each document open if you do something like this:
Open foo.ipynb (A kernel in metadata) foo.ipynb added to A perferredWith
Change to kernel B in foo.ipynb
Execute
Close foo.ipynb
Open foo.ipynb (B kernel in metadata) foo.ipynb added to B preferredWith

Seems like that situation would be wrong then if I'm following right.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not following the mistake? Because A would still be preferred? Yeah seems like map should be the other way. Map between notebook (key) and controller (value)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, trying to make sure that I'm reading it right. As I see it now PreferredWith is all the notebook documents that this controller is the preferred controller for. Given that the preferred controller could change if you execute and reopen a document you could have the same document in the preferred list for two different controllers. As documents only have one preferred (at least from our extensions perspective) that situation wouldn't be right.

// Parse the HTML for our expected variables
const expectedVariables = [
{ name: 'test', type: 'str', length: '11', value: ' MYTESTVALUE' },
{ name: 'test2', type: 'str', length: '12', value: ' MYTESTVALUE2' }
];
verifyViewVariables(expectedVariables, htmlResult);
await waitForVariablesToMatch(expectedVariables, variableView);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, much better.

@@ -43,6 +43,8 @@ env:
IPYWIDGET_SCREENSHOT_PATH: '*-screenshot.png'
DISABLE_INSIDERS_EXTENSION: 1 # Disable prompts to install Insiders in tests (else it blocks activation of extension).
VSC_JUPYTER_INSTRUMENT_CODE_FOR_COVERAGE: true
VSIX_NAME_PYTHON: 'ms-python-insiders.vsix'
VSC_JUPTYER_PYTHON_EXTENSION_VERSION: 'stable'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean, if this is stable, then we use Stable VS Code & stable Python extension
& if its insider we use vscode insiders & python insiders?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's just a flag for now. It makes it easy to switch this later.

@@ -13,6 +13,7 @@ export interface INotebookControllerManager {
// Marked test only, just for tests to access registered controllers
registeredNotebookControllers(): VSCodeNotebookController[];
getInteractiveController(): Promise<VSCodeNotebookController | undefined>;
getPreferredNotebookController(document: NotebookDocument): VSCodeNotebookController | undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is being used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used in the helper.ts file to find the closest match for a kernel.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically the the tests that used to call waitForKernelToGetAutoSelected are now instead waiting for the preferred kernel to be auto selected (which effectively is the same as what happened before)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes found that.

if (!isRightKernel()) {
traceInfoIf(isCI, `Notebook select.kernel command switching to kernel id ${id}: Try ${tryCount}`);
// Send a select kernel on the active notebook editor. Keep sending it if it fails.
await commands.executeCommand('notebook.selectKernel', { id, extension: JVSC_EXTENSION_ID });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this needs to be ezecuted multiple times, i think once is sufficient, and after that we just need to keep waiting until the right kernel is selected.
Else we keep firing this command multkiple times & i'm concerned we could have other side effects of filing this unnecessarily

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not what I found. There was a potential race between 'createNotebookController (and results getting to VS code proper)' and the 'notebook.selectKernel' command coming in. This race went away when I did this in a loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously we didn't even care if it worked (hence the comment in the setAsActiveControllerForTests). And we'd set and forget it. But sometimes it didn't work.

With this loop it seems to always work.

Copy link
Contributor

@DonJayamanne DonJayamanne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@rchiodo rchiodo merged commit b7241b5 into main Sep 22, 2021
@rchiodo rchiodo deleted the rchiodo/intellisense_tests branch September 22, 2021 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants