-
Notifications
You must be signed in to change notification settings - Fork 293
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
Conversation
Codecov Report
@@ 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
|
return []; | ||
} else { | ||
traceInfoIf(isCI, `Completions found, filtering the list: ${JSON.stringify(result)}.`); |
There was a problem hiding this comment.
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 traceIfCIor
traceOnCI` is simpler.
Absolutely no need to make that change, just a thought
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
…ew to use waitForCondition instead of trying to track messages
@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 |
await this.setAsActiveControllerForTests(notebook); | ||
|
||
// Keep track of if this controller is preferred for this notebook | ||
if (affinity === NotebookControllerAffinity.Preferred) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, much better.
…est was not finding it even though it was using it to run
@@ -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' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 }); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
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.