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

Functional tests for the Getting Started page #11850

Merged

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented May 17, 2017

This PR starts to add some functional tests for the Getting Started page. Specifically, it adds functional tests that exercise the scenarios under which a user should or should not get redirected to the Getting Started page.

It also does a small bit of refactoring in the Console tests that use the Getting Started page object to opt out of the Getting Started page.

class GettingStartedPage {
async clickOptOutLink() {
log.debug('Clicking opt-out link');
await testSubjects.click('lnkGettingStartedOptOut');
}

async optOutLinkExists() {
return await testSubjects.exists('lnkGettingStartedOptOut');
Copy link
Contributor

Choose a reason for hiding this comment

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

Super minor, but this seems the only method that doesn't have a log.debug


const log = getService('log');
const testSubjects = getService('testSubjects');

const PageObjects = getPageObjects(['common']);

class GettingStartedPage {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this even an instantiated class? I'm not seeing any local state or anything. All the methods just call static methods, or instance methods off already instantiated objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure TBH. I was following the pattern already established with other page objects. If we want to change this pattern I suggest we open a new issue for doing it across the board for all page objects and then fix it there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

// delete .kibana index and update configDoc
await kibanaServer.uiSettings.replace({
'dateFormat:tz':'UTC',
'defaultIndex':'logstash-*'
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe not a better way, but does this defaultIndex need to match anything else that is setup in the test runner? I'd just want to avoid a scenario where this value is configured somewhere, it's copied here, but then someone possibly changes the value later in the future and this test breaks and it's not clear why. It's entirely possible that I'm missing something but just wanted to point it out in case it could happen

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, I see what you mean. There's an implicit dependency here between this line and the await esArchiver.load('discover'); line a couple of lines further down. It would probably be better to create a wrapper method somewhere like loadDefaultIndex that loads the actual data using esArchiver.load but also sets up the defaultIndex value, and then use that wrapper method here.

All that said, this here is a pattern that is already established and being used in several places. So I suggest we open an issue for fixing this across the board rather than increasing the scope of this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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


const PageObjects = getPageObjects(['common', 'gettingStarted']);

describe('Getting Started page', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we have a test that ensures the navigation is displayed properly when the user manually navigates to the Getting Starting page from the Management page?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added this as part of 5351e61.

@@ -19,9 +19,9 @@ export default function ({ getService, getPageObjects }) {

describe('console app', function describeIndexTests() {
before(async function () {
await PageObjects.gettingStarted.optOut();
Copy link
Contributor

Choose a reason for hiding this comment

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

See #11881

await kibanaServer.uiSettings.replace({});
});

describe('when user has not opted out of Getting Started page', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

You might want to add a before hook here that ensures that the getting started local storage entry is not set, with remote.deleteLocalStorageItem() https://theintern.github.io/leadfoot/module-leadfoot_Command.html#deleteLocalStorageItem

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When I try this I get this error:

           │             [DELETE http://localhost:9515/session/dfa8779e7e55a011f085086a3a75031b/local_storage/key/kibana.isGettingStartedOptedOut] <unknown>: Failed to read the 'localStorage' property from'Window': Access is denied for this document.
           │         (Session info: chrome=58.0.3029.110)
           │         (Driver info: chromedriver=2.29.461585 (0be2cd95f834e9ee7c46bcc7cf405b483f5ae83b),platform=Mac OS X 10.12.4 x86_64)

Copy link
Contributor

Choose a reason for hiding this comment

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

Huh, weird

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think its because the Kibana web site hasn't been loaded up at that point.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I have a fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed as part of 6334019.

@ycombinator ycombinator force-pushed the getting-started/functional-tests branch 2 times, most recently from 5351e61 to 111c9d7 Compare May 19, 2017 11:42
@ycombinator
Copy link
Contributor Author

@chrisronline @spalger I've addressed review comments and rebased after #11881 was merged recently. This is ready for your 👀 again. Thanks!

Copy link
Contributor

@chrisronline chrisronline left a comment

Choose a reason for hiding this comment

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

LGTM. Just some minor notes

@@ -79,23 +79,28 @@ export function CommonPageProvider({ getService, getPageObjects, getPageObject }

if (loginPage && !wantedLoginPage) {
log.debug(`Found loginPage username = ${config.get('servers.kibana.username')}`);
await PageObjects.shield.login(
return PageObjects.shield.login(
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the reason behind these changes? Do you need the checking to live in a promise chain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, these changes don't look right. They are probably a result of this PR co-existing with #11881 at one point and all the rebasing that was happening at the time. I'm going to update this PR with only commits related to it. Stay tuned!

@ycombinator ycombinator force-pushed the getting-started/functional-tests branch 2 times, most recently from 7cf3ee7 to 36ce0eb Compare May 19, 2017 14:26
@ycombinator
Copy link
Contributor Author

Jenkins, test this

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

@ycombinator
Copy link
Contributor Author

ycombinator commented May 22, 2017

Thanks, I've removed that line in 5089559. Will merge once CI goes green.

@ycombinator ycombinator force-pushed the getting-started/functional-tests branch from 83460ae to 5089559 Compare May 23, 2017 00:00
@ycombinator ycombinator merged commit 099178a into elastic:master May 23, 2017
ycombinator added a commit that referenced this pull request May 23, 2017
* Adding some more functionality to the Getting Started page object

* Using optOut method from Getting Started page object

* Adding functional tests for Getting Started page

This set of tests specifically tests the scenarios under which a user should or should not get redirected to the Getting Started page

* Adding log.debug message

* Conforming to HTML style guide

* Using new GettingStarted page object methods + opting out

* Adding test for nav being shown

* Removing unnecessary line

* Navigate to Discover expecting to be redirected to the Getting Started page

* Trying beforeEach instead of before

* Remove LS data index + load empty kibana index

* Removing unnecessary line

* Fixing order of operations
@ycombinator
Copy link
Contributor Author

Backported to:

  • 5.x / 5.5: ae16cb3

@ycombinator ycombinator deleted the getting-started/functional-tests branch May 23, 2017 14:09
snide pushed a commit to snide/kibana that referenced this pull request May 30, 2017
* Adding some more functionality to the Getting Started page object

* Using optOut method from Getting Started page object

* Adding functional tests for Getting Started page

This set of tests specifically tests the scenarios under which a user should or should not get redirected to the Getting Started page

* Adding log.debug message

* Conforming to HTML style guide

* Using new GettingStarted page object methods + opting out

* Adding test for nav being shown

* Removing unnecessary line

* Navigate to Discover expecting to be redirected to the Getting Started page

* Trying beforeEach instead of before

* Remove LS data index + load empty kibana index

* Removing unnecessary line

* Fixing order of operations
ycombinator added a commit to ycombinator/kibana that referenced this pull request Jun 2, 2017
ycombinator added a commit to ycombinator/kibana that referenced this pull request Jun 3, 2017
ycombinator added a commit that referenced this pull request Jun 5, 2017
* Revert "When on an embedded page, bypass Getting Started gate check (#12040)"

This reverts commit 05293f1.

* Revert "Making tweaks. (#12003)"

This reverts commit aa3fa06.

* Revert "Functional tests for the Getting Started page (#11850)"

This reverts commit 099178a.

* Revert "Prevent flicker on Getting Started page (#11826)"

This reverts commit c4b3ade.

* Revert "Getting Started page (#11805)"

This reverts commit 32eff37.

* Remove check for Getting Started page from navigateToApp
ycombinator added a commit that referenced this pull request Jun 5, 2017
* Revert "When on an embedded page, bypass Getting Started gate check (#12040)"

This reverts commit 05293f1.

* Revert "Making tweaks. (#12003)"

This reverts commit aa3fa06.

* Revert "Functional tests for the Getting Started page (#11850)"

This reverts commit 099178a.

* Revert "Prevent flicker on Getting Started page (#11826)"

This reverts commit c4b3ade.

* Revert "Getting Started page (#11805)"

This reverts commit 32eff37.

* Remove check for Getting Started page from navigateToApp
PopradiArpad pushed a commit to PopradiArpad/kibana that referenced this pull request Jun 6, 2017
* Revert "When on an embedded page, bypass Getting Started gate check (elastic#12040)"

This reverts commit 05293f1.

* Revert "Making tweaks. (elastic#12003)"

This reverts commit aa3fa06.

* Revert "Functional tests for the Getting Started page (elastic#11850)"

This reverts commit 099178a.

* Revert "Prevent flicker on Getting Started page (elastic#11826)"

This reverts commit c4b3ade.

* Revert "Getting Started page (elastic#11805)"

This reverts commit 32eff37.

* Remove check for Getting Started page from navigateToApp
chrisronline pushed a commit to chrisronline/kibana that referenced this pull request Jun 14, 2017
* Revert "When on an embedded page, bypass Getting Started gate check (elastic#12040)"

This reverts commit 05293f1.

* Revert "Making tweaks. (elastic#12003)"

This reverts commit aa3fa06.

* Revert "Functional tests for the Getting Started page (elastic#11850)"

This reverts commit 099178a.

* Revert "Prevent flicker on Getting Started page (elastic#11826)"

This reverts commit c4b3ade.

* Revert "Getting Started page (elastic#11805)"

This reverts commit 32eff37.

* Remove check for Getting Started page from navigateToApp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants