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

Reinstate and skip Dashboard and Visualize tests #15687

Merged
merged 2 commits into from
Dec 19, 2017
Merged
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
32 changes: 32 additions & 0 deletions style_guides/testing_style_guide.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Testing style guide

## Principles

* A good test helps you identify what broke and how so you can fix it quickly. A bad test tells you something is broken but wastes your time trying to figure out what and how.
* Tests add time to the development cycle so we should write as few tests as possible, but no fewer.
* **Unit tests** should cover 70% of our needs. They'll ensure our fundamentals are sound.
* **Integrations tests** should cover 20% of our needs. They'll ensure our units work well together.
* **End-to-end tests** should cover 10% of our needs. They'll ensure our primary user flows are intact and alleviate the burden of manual testing from our QA engineers.
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel a bit like these numbers are arbitrary and don't accurately reflect our needs given the state of our code base. End to end tests require updating when our UI/UX changes, but they don't require updating when the inner code changes. Unit tests and integration tests require updating when our code changes, but not when the UI/UX changes. If we had a more stable code base then I think I'd agree that unit tests should be the focus, but we don't. Many of the bugs we actually find in production can't be covered by a unit tests. Unit tests aren't easy to create if the code doesn't have clear boundaries between logic and UI, which many places of our code base don't. In addition, a large portion of our codebase is in a transition from angular to react and undergoing a lot of clean up and refactoring. We should be writing unit tests for new code where possible, but I think code thats undergoing a big refactor means it's even more important to have end to end tests to ensure all the corner cases still work. It also eases the burden on our QA team.

I think a good principle to have is that any time a bug is encountered, write a test that would have caught it, whether it be a unit tests or an integration test, or an end to end test, but don't change the code prior to adding the test. I've been trying to do this and most of the time the only way to cover the test is an end to end test.


## Anti-patterns

### Too many assertions in a single test

A test's usability goes down as the number of assertions it contains goes up. The more assertions you make, the less clear the purpose of the test.

Instead of doing this, try one of these alternatives:

1. Try breaking up the test into multiple tests with individual assertions. This clarifies what you're testing.
2. Try using Jest snapshots in lieu of multiple assertions about the state of the UI. This makes your test more concise and maps it more clearly to the appearance of the UI.

### Testing concrete details instead of abstractions

Let's say a feature in your UI consists of a form and a submit button. If you want to test that this feature is available, then making an assertion against the form inputs and submit button would be a test of the feature's concrete details. This would be a brittle test that's prone to being broken by changes to the form's design or to the UX of the feature.

A better test would test for the abstract availability of this feature. For example, a `data-test-subj` selector on the container or some other proxy element to ensure the user has access to the feature.

### PageObject method does too much

### PageObject method contains conditional logic

### PageObject is bloated
47 changes: 47 additions & 0 deletions test/functional/apps/dashboard/_view_edit.js
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,27 @@ export default function ({ getService, getPageObjects }) {
await PageObjects.dashboard.gotoDashboardEditMode(dashboardName);
});

it.skip('when time changed is stored with dashboard', async function () {
const originalFromTime = '2015-09-19 06:31:44.000';
const originalToTime = '2015-09-19 06:31:44.000';
await PageObjects.header.setAbsoluteRange(originalFromTime, originalToTime);
await PageObjects.dashboard.saveDashboard(dashboardName, { storeTimeWithDashboard: true });
await PageObjects.header.clickToastOK();

await PageObjects.dashboard.clickEdit();
await PageObjects.header.setAbsoluteRange('2013-09-19 06:31:44.000', '2013-09-19 06:31:44.000');
await PageObjects.dashboard.clickCancelOutOfEditMode();

// confirm lose changes
await PageObjects.common.clickConfirmOnModal();

const newFromTime = await PageObjects.header.getFromTime();
const newToTime = await PageObjects.header.getToTime();

expect(newFromTime).to.equal(originalFromTime);
expect(newToTime).to.equal(originalToTime);
});

it('when the query is edited and applied', async function () {
const originalQuery = await PageObjects.dashboard.getQuery();
await PageObjects.dashboard.setQuery(`${originalQuery} and extra stuff`);
Expand Down Expand Up @@ -137,6 +158,32 @@ export default function ({ getService, getPageObjects }) {
});
});

describe.skip('and preserves edits on cancel', function () {
it('when time changed is stored with dashboard', async function () {
await PageObjects.dashboard.gotoDashboardEditMode(dashboardName);
const newFromTime = '2015-09-19 06:31:44.000';
const newToTime = '2015-09-19 06:31:44.000';
await PageObjects.header.setAbsoluteRange('2013-09-19 06:31:44.000', '2013-09-19 06:31:44.000');
await PageObjects.dashboard.saveDashboard(dashboardName, true);
await PageObjects.header.clickToastOK();
await PageObjects.dashboard.clickEdit();
await PageObjects.header.setAbsoluteRange(newToTime, newToTime);
await PageObjects.dashboard.clickCancelOutOfEditMode();

await PageObjects.common.clickCancelOnModal();
await PageObjects.dashboard.saveDashboard(dashboardName, { storeTimeWithDashboard: true });
await PageObjects.header.clickToastOK();

await PageObjects.dashboard.loadSavedDashboard(dashboardName);

const fromTime = await PageObjects.header.getFromTime();
const toTime = await PageObjects.header.getToTime();

expect(fromTime).to.equal(newFromTime);
expect(toTime).to.equal(newToTime);
});
});

describe('Does not show lose changes warning', async function () {
it('when time changed is not stored with dashboard', async function () {
await PageObjects.dashboard.gotoDashboardEditMode(dashboardName);
Expand Down
Empty file.
50 changes: 50 additions & 0 deletions test/functional/apps/visualize/_gauge_chart.js
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,56 @@ export default function ({ getService, getPageObjects }) {
});
});

it.skip('should show Split Gauges', function () {
const expectedTexts = [ 'win 8', 'win xp', 'win 7', 'ios', 'osx' ];
return PageObjects.visualize.clickMetricEditor()
.then(function clickBucket() {
log.debug('Bucket = Split Group');
return PageObjects.visualize.clickBucket('Split Group');
})
.then(function selectAggregation() {
log.debug('Aggregation = Terms');
return PageObjects.visualize.selectAggregation('Terms');
})
.then(function selectField() {
log.debug('Field = machine.os.raw');
return PageObjects.visualize.selectField('machine.os.raw');
})
.then(function clickGo() {
return PageObjects.visualize.clickGo();
})
.then(function () {
return retry.try(function tryingForTime() {
return PageObjects.visualize.getGaugeValue()
.then(function (metricValue) {
expect(expectedTexts).to.eql(metricValue);
});
});
});
});

it.skip('should show correct values for fields with fieldFormatters', async function () {
const expectedTexts = [ '2,904\nwin 8: Count', '5.528KB' ];


await PageObjects.visualize.clickMetricEditor();
await PageObjects.visualize.clickBucket('Split Group');
await PageObjects.visualize.selectAggregation('Terms');
await PageObjects.visualize.selectField('machine.os.raw');
await PageObjects.visualize.setSize('1');
await PageObjects.visualize.clickAddMetric();
await PageObjects.visualize.clickBucket('Metric');
await PageObjects.visualize.selectAggregation('Average', 'metrics');
await PageObjects.visualize.selectField('bytes', 'metrics');
await PageObjects.visualize.clickGo();

return retry.try(function tryingForTime() {
return PageObjects.visualize.getGaugeValue()
.then(function (metricValue) {
expect(expectedTexts).to.eql(metricValue);
});
});
});
});
});
}