[scout] An abstraction for extending pageObjects

[mattkime]

Summary

There's a bit of repeated boilerplate code necessary for adding pageObject functionality. This PR abstracts it so it can be replaced with a single line of code.

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• See some risk examples
• ...

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!
• Click to trigger kibana-deploy-cloud-from-pr for this PR!

[mattkime]

Would prefer a better solution than using as PageObjectsExtended but it was the best I could do.

Also, I bet a number of these things could be better named.

[mattkime]

looks like this could be done for the lighthouseTest and spaceTest as well

[mattkime]

Perhaps extendTest or extendPageObjects would make more sense

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e0b11e1

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/scout	190	195	+5

Unknown metric groups

API count

id	before	after	diff
@kbn/scout	525	530	+5

[mattkime]

This is the result I desired, a simple and terse way to extend the set of page objects. The createTest function is dense and difficult to read but the code it replaces didn't have any more meaning as best I could tell.

[csr]

createTest() is only extending the pageObjects fixture (test-scoped) but notice it still passes two type parameters to base.extend(): test-scoped fixtures and worker-scoped fixtures. It seems to me here we limit the scope of what you can do with createTest to just page object creation, which imho isn't ideal.

See some examples of Scout packages and plugins extending multiple fixtures (not just pageObjects) using base.extend():

• The Security Scout package extends both pageObjects and apiServices here.
• The Scout Observability package is extending both fixtures as well here.
• The APM plugin extends both pageObjects and browserAuth here.

What I appreciate about the current architecture is how flexible it is when it comes to extending any Scout core fixture (test-scoped and worker-scoped) to expose additional methods. While your method is convenient I'm afraid it will limit what plugins (but most especially Scout packages) can expose to other plugins. What do you think?