[MGNLTEST-60] Reinstate page object extraction initiative Created: 28/May/19  Updated: 07/Jul/20  Resolved: 12/Aug/19

Status: Closed
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Federico Grilli
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 3d
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLTEST-53 Start productizing page object initia... Closed
Relates
relates to MGNLCE-141 Point UI tests to M5 compatibility ad... Closed
relation
is related to MGNLTEST-58 POC for „Page objects“ - 1st step for... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: core-TF-features-bugs-improvements
Story Points: 5

 Description   

Carry on with the refactoring which started before 6.0 release. Continue tearing info.magnolia.integrationtests.uitest.AbstractMagnoliaUITest class apart (see the examples of e.g. info.magnolia.integrationtests.pageobjects.AdminCentralM5Impl or its M6 counterpart, or Findbar page object.

Assess the current state, see which other page objects can be extracted, apply them to the existing tests and see if the test complexity empirically reduces.

Outcome:

  • estimate the total effort of propagating the refactoring onto entire UI test suite
  • decide whether the achievable result matches the expectations (DEV-1197)
  • fgrilli to summarise the further steps and collect the necessary opinions and info from the stakeholders


 Comments   
Comment by Mikaël Geljić [ 11/Jun/19 ]

See https://git.magnolia-cms.com/projects/PLATFORM/repos/ce/pull-requests/144/overview for previously adjusted selectors

Comment by Federico Grilli [ 12/Aug/19 ]

I would suggest that this dev ticket be closed and its outcome, as summarised in the wiki page (and partly in the PoC PR) taken as the basis for moving on with more specific tasks.
In particular, we need to define the Page objects API: mgeljic suggested a different approach with

a factory or provider for "high-order pages" , i.e. the main views a user sees in the foreground, similar to what #openApp returns at the moment, not necessarily in a static way.
Such views could be:
contentApp - would return/reflect a browser sub-app (browser is the first thing open when we expect to see a content app the first time)
detailSubApp
dialog
alerts/confirmDialogs (anything displayed in un-rooted Vaadin overlays)
findBar
appLauncher
loginPage
licensePage

Comment by Mikaël Geljić [ 12/Aug/19 ]

For what it's worth I don't necessarily see that as a different approach, only maybe a tad less granular (with a naming exercise).
Relevant question on the PR: to what extent page-objects should return the app's next state, if at all?

Generated at Mon Feb 12 07:45:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.