Create UI test to verify Developer perspective

[pmacik]

This PR adds a new UI test that:

• Installs latest OS console
• Installs Dev Console
• Adds a non-admin user
• Verifies that Developer Perspective appears in UI for the user after the Dev Console is installed:
  • Login the user in UI
  • Check for the perspective switcher button in UI
  • Verify the Developer perspective is present

Depends on:

• #210 - Add chromedriver to the tools images
• #212 - Add missing chromium package to the tools images
• #215 - Install htpasswd to the tools images for CI

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: tinakurian

If they are not already assigned, you can assign the PR to them by writing /assign @tinakurian in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

Hi @pmacik. Thanks for your PR.

I'm waiting for a redhat-developer member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[pratikjagrut]

/ok-to-test

[openshift-ci-robot]

@pratikjagrut: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[akashshinde]

/ok-to-test

[pmacik]

Depends on:

• Add chromedriver to the tools images #210
• Add missing chromium package to the tools images. #212

[ldimaggi]

One suggestion - I have noticed that there are intermittent timing issues related to the appearance of the UI elements in the Developer Perspective in the UI - I assume that this is due to the DOM being updated.

It would be a good idea for the test to be robust enough to avoid 'element not fund' errors. I'd suggest making this change:

// MaxCount = Max count for loop used to discover UI elements
const MaxCount = 10

//FindElementBy look for a web element by a given selector and returs it back when found.
func FindElementBy(t *testing.T, wd selenium.WebDriver, by string, selector string) selenium.WebElement {

	var elems []selenium.WebElement
	elems, err := wd.FindElements(by, selector)

	// To avoid a problem where the element is yet not present
	counter := 0
	for {
		if len(elems) > 0 || counter > MaxCount {
			break
		}
		counter++
		time.Sleep(100 * time.Millisecond)
	}

	elem, err := wd.FindElement(by, selector)
	require.NoError(t, err, fmt.Sprintf("Find element by %s=%s", by, selector))
	return elem
}

[pmacik]

@ldimaggi Thanks for that idea. I implemented it in 83a06e5

[ldimaggi]

On May 20, we discussed how we wanted the UI test to always begin from a "clean" starting point. In the context of the UI test this requires that a new console be created. Pavel suggested that we could clone/copy the test setup steps defined for the OLM integration test (test-olm-integration) as these steps do create a new cluster. I'd vote for this approach instead of appending the UI test(s) to the OLM integration test target as we should keep the tests separated by function/goal.

[pmacik]

/retest