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

Docs: Add smoke test examples to datasource guides #1329

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,18 @@ In many cases, the execution of annotation queries requires different handling t

If your data source plugin implements a custom annotation editor, you can write tests that verify that the editor works as expected. If you haven't implemented a custom editor, then the plugin will use the built-in in editor. In that case, you don't need to write tests.

The following example is a simple smoke test that verifies that a custom annotation editor loads.

```ts title="annotations.spec.ts"
import { expect, test } from '@grafana/plugin-e2e';

test('should render annotations editor', async ({ annotationEditPage, page, readProvisionedDataSource }) => {
const ds = await readProvisionedDataSource({ fileName: 'datasources.yml' });
await annotationEditPage.datasource.set(ds.name);
await expect(page.getByRole('textbox', { name: 'Query Text' })).toBeVisible();
});
```

### Test the entire annotation query execution flow

In the next example, we perform an integration test where we test a plugin's entire annotation query data flow.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,20 @@ sidebar_position: 10

Most data source plugins need authentication to communicate with third-party services. The appropriate place to configure the connection details is the data source configuration page, and the details there must be valid so that the health check endpoint used to test the configuration works as expected.

### Test that the configuration editor loads

The following example is a simple smoke test that verifies that the data source configuration editor loads.

```ts title="configurationEditor.spec.ts"
import { test, expect } from '@grafana/plugin-e2e';

test('should render config editor', async ({ createDataSourceConfigPage, readProvisionedDataSource, page }) => {
const ds = await readProvisionedDataSource({ fileName: 'datasources.yml' });
await createDataSourceConfigPage({ type: ds.type });
await expect(page.getByLabel('Path')).toBeVisible();
});
```

### Testing the configuration in a backend data source plugin

Backend data sources implement a [health check](../../key-concepts/backend-plugins/#health-checks) endpoint that is used to test whether the configuration is valid or not. In the following example, the configuration editor form is populated with valid values then the `Save & test` button is clicked. Clicking `Save & test` calls the Grafana backend to save the configuration, then passes configuration to the plugin's backend health check endpoint. The test will be successful only if both calls yields a successful status code.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,21 @@ sidebar_position: 30

[Variable queries](https://grafana.com/docs/grafana/latest/dashboards/variables/add-template-variables/#add-a-query-variable) allow users to query a data source to load lists of data such as metric names. You can then reference variables in queries to make your dashboards more interactive and dynamic. If your data source plugin implements the custom variable support API, you may want to use the `variableEditPage` fixture to test that your plugin's variable implementation works as expected.

### Test the custom variable editor
### Test that the custom variable editor loads

The following example is a simple smoke test that verifies that the custom variable editor loads.

```ts title="customVariableEditor.spec.ts"
import { expect, test } from '@grafana/plugin-e2e';

test('should render variable editor', async ({ variableEditPage, page, readProvisionedDataSource }) => {
const ds = await readProvisionedDataSource({ fileName: 'datasources.yml' });
await variableEditPage.datasource.set(ds.name);
await expect(page.getByRole('textbox', { name: 'Query Text' })).toBeVisible();
});
```

### Test the custom variable editor in isolation

In the following example, we test that the custom variable editor renders a certain field when the `ListByDimensions` query type is chosen:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,20 @@ sidebar_position: 20

The query editor is a central piece of a data source plugin as this is where users craft the query that is used to fetch data. Your data source plugin can provide a rich query editor which allows various query types that target different APIs. Your query editor can even have features such as visual query builders, IntelliSense, and autocompletion.

### Test that the query editor loads

The following example is a simple smoke test that verifies that the data source query editor loads.

```ts title="queryEditor.spec.ts"
import { test, expect } from '@grafana/plugin-e2e';

test('should render query editor', async ({ panelEditPage, readProvisionedDataSource }) => {
const ds = await readProvisionedDataSource({ fileName: 'datasources.yml' });
await panelEditPage.datasource.set(ds.name);
await expect(panelEditPage.getQueryEditorRow('A').getByRole('textbox', { name: 'Query Text' })).toBeVisible();
});
```

### Test parts of the query editor in isolation

In the following example, the query editor loads regions via a request to `/regions` and filters out the ones containing `gov` before populating them in a dropdown menu.
Expand Down
Loading