-
Notifications
You must be signed in to change notification settings - Fork 31
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
Plugin E2E: Make it possible to test query editor in panel edit page #551
Conversation
Hello! 👋 This repository uses Auto for releasing packages using PR labels. ✨ This PR can be merged. It will not be considered when calculating future versions of the npm packages and will not appear in the changelogs. |
@@ -1,7 +1,8 @@ | |||
{ | |||
"compilerOptions": { | |||
"outDir": "./dist", | |||
"declaration": true | |||
"declaration": true, | |||
"stripInternal": true |
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.
Would like some types to be internal so added this option. Maybe this should go in the base config? Thoughts @jackw?
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.
Just out of curiosity - how do we decide which types should be private and which ones should be public? I sometimes find it useful during development to have access to as many types as possible when working with a package, while on the other hand it can tie our hands if we expose too much, as we can hardly change what a lot of people depend on.
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.
Good question. Think I just don't want to overload consumer with irrelevant types etc. But may be better to save this for later.
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 work, I really like the explanatory comments, they helped a lot with reviewing. 👏 Generally looks good to me, left a few comments.
* | ||
* If you have tests that depend on the the existance of a data source, | ||
* you may use this command in a setup project. Read more about setup projects | ||
* here: https://playwright.dev/docs/auth#basic-shared-account-in-all-tests |
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.
Just an idea: I think this comment is ok as it is and already really useful, however maybe in the future we could add some Grafana-related examples which we could link to from here as well.
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 100%! Actually this comment was made before I knew that it's possible to use env variables in provisioning files. That kind of makes this comment obsolete. I'll change it. But we should definitely have examples of using provisioning with (and without) secrets in plugin-examples eventually.
await this.ctx.page | ||
.getByLabel(this.ctx.selectors.components.PanelEditor.General.content) | ||
.locator(`selector=${this.ctx.selectors.components.TimePicker.openButton}`) | ||
.click({ force: true, timeout: 2000 }); |
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.
Why do we need the 2000ms
timeout here?
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.
Good question...this is mostly copied from plugin/e2e in grafana core. I'll remove it and we'll see. If timeout is not provided explicitly like in this case, timeout from playwright config will be used. It defaults to 5000ms if I recall correctly. Will changed this!
.click({ force: true, timeout: 2000 }); | ||
} catch (e) { | ||
// seems like in older versions of Grafana the time picker markup is rendered twice | ||
await this.ctx.page.locator('[aria-controls="TimePickerContent"]').last().click(); |
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.
Could it be that the error is caused by something else?
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.
Unlikely, but maybe. Anyway, I don't like this so I'll add a todo
for finding a better solution for this. Have a bunch of todos throughout the code...most of them involves changes in Grafana ui so would like to collect a few before I get to them.
@@ -11,6 +11,6 @@ test('valid credentials should return a 200 status code', async ({ createDataSou | |||
const configPage = await createDataSourceConfigPage({ type: 'grafana-googlesheets-datasource' }); | |||
await page.getByText('Google JWT File', { exact: true }).click(); | |||
await page.getByTestId('Paste JWT button').click(); | |||
await page.getByTestId('Configuration text area').fill(process.env.GOOGLE_JWT_FILE!); | |||
await page.getByTestId('Configuration text area').fill(process.env.GOOGLE_JWT_FILE!.replace(/'/g, '')); |
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.
Just out of curiosity, why do we need to remove the '
single quotes here?
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.
This variable is also used here in the provisioning file for google sheets. Seems like the jwt file needs to be wrapped in single quotes for provisioning to work, so that's how the GH secret is defined. That however doesn't work when creating a new sheets ds using the UI, so therefore I'm removing the single quotes.
packages/plugin-e2e/tests/datasource/queryEditor.integration.spec.ts
Outdated
Show resolved
Hide resolved
|
||
await panelEditPage.refreshPanel(); | ||
await expect(await queryReq).toBeTruthy(); | ||
}); |
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.
What's the "semantic" difference between the tests in queryEditor.integration.spec.ts
and queryEditor.spec.ts
? In other words, how do we suggest to organise tests?
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 a good question!
queryEditor.spec.ts
just tests the query editor. I.e checking the right endpoints are being called when a certain button is clicked and so on. I want to test the query editor in isolation, so any backend endpoints are mocked.
queryEditor.integration.spec.ts
is calling the downstream sheets API and fetches data from a readonly spreadsheet.
Ultimately, it will be up to the plugin author to decide what kind of tests they want to have. Both may be useful. Hitting real downstream APIs can be very useful, but it may come with security concerns and also cause flakiness.
@@ -1,7 +1,8 @@ | |||
{ | |||
"compilerOptions": { | |||
"outDir": "./dist", | |||
"declaration": true | |||
"declaration": true, | |||
"stripInternal": true |
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.
Just out of curiosity - how do we decide which types should be private and which ones should be public? I sometimes find it useful during development to have access to as many types as possible when working with a package, while on the other hand it can tie our hands if we expose too much, as we can hardly change what a lot of people depend on.
Co-authored-by: Levente Balogh <balogh.levente.hu@gmail.com>
Co-authored-by: Levente Balogh <balogh.levente.hu@gmail.com>
Co-authored-by: Levente Balogh <balogh.levente.hu@gmail.com>
Thanks for good feedback @leventebalogh! |
What this PR does / why we need it:
This PR adds fixtures, models and expect matchers that enable testing a data source query editor in the panel edit page.
A few things to note:
Sorry for the large amount of files changed. Wanted the PR to include all the pieces that is needed to test a query editor so one can review this as a full feature. Let me know if you want me to try and split the PR.
Which issue(s) this PR fixes:
Part of grafana/grafana#78078
Fixes #
Special notes for your reviewer: