Moving Nala to POMs over .selectors.js module exports

[amauch-adobe]

I wanted to start a location for going over everyone's opinions, thoughts, and hopefully a decision on how things should be set up going forward for Nala in regards to the usage of POMs (Page Object Models) or the .selectors.js module export files.

Daniel Chivescu from the FEDS team has proposed a few templates and proposed methods for having POMs (which Playwright out-of-the-box supports) for organizing, minimalizing, and page reuse for methods and selectors. This would remove having tons of lib methods for different test cases across multiple test files. I think the original idea for selectors module exports was great for testing milo blocks/features, which was how Nala was first put together, but for testing different applications that span functionality across different pages, it isn't as robust, clean, and scalable.

I propose we use POMs when it makes sense, as Daniel put out in his first template PR for FEDS. POMs I believe should not become bulky, cluttered, or have massive amounts of multi-inheritance since that makes tests also difficult to understand since there are so many pages to drive through. Daniel made a good argument here:

There is a reason why multiple inheritance is not allowed in JS and other higher-level programming languages! I first considered using a section > page >> page1 | page2 | page3 >> (multiple inheritance) specific-page approaches, but seeing how cluttered and unmaintainable the Platform-UI variant has become by using polytype mixins is something I think we don't think would be desirable in NALA. The end result is large, cluttered pages that inherit from multiple client sections/pages and become unreadable and unmaintainable. Thus, every client should create their own page objects on-demand, following this simple pattern.

I do think selector files work for some cases, i.e. quick block tests, but for Federated services having POMs to me makes more sense and probably should be contributed to Nala Core since all Milo-based sites will probably use them. That being said I do believe there needs to be careful consideration as to what things go inside POMs, when a POM should be created, and meticulous discretion/forbearance on testing templated pages/functionality over and over again.

• What are the communities thoughts about the addition/change?
• How should repo folder structure be, I believe @skumar09 has already posed a direction which he can enlighten here.
• Clarity and process for POM creation and use? (The whens, whys, and hows). Daniel's proposed ideas are here in these PRs: [MWPW-128180] Added FEDS user-profile checks  nala#90, [MWPW-126969] Added search component check & page-objects nala#79
• Usage for selectors files? Should they be continued in use and when should they be used?

[amauch-adobe]

Here is Playwright's documentation on POMs: https://playwright.dev/docs/pom

[skumar09]

• Conceptually current selector.js and POM are similar (i.e. in terms of separating locators from tests), but POM is better as it will have both locators and methods in it.
• I would vote to have POM approach to Nala core. At the same time we have keep Nala as lite as possible, as @Aaron Mauchley pointed we need to make sure what should go into page objects and not have any unused or good to have methods/functions
• As in future Nala will be made consumable application, common methods ( i.e. one that can be used across applications) should go in to libs folder.

[JackySun9]

This is good, we should have as soon as possible

[Dli3]

I think the addition would be beneficial for those who'll need it.