Description

The Page Object Model (POM) is a design pattern that promotes code reusability and maintainability in e2e testing by encapsulating UI element selectors and interactions within page objects. This initial PR is the beginning of integrating POM into e2e test suite, aiming to enhance test code quality.

The entire implementation is done in TypeScript instead of JavaScript.

Key Considerations for Implementation:

• Easy Adaptation: ensure that the structure is straightforward and intuitive, thereby accelerating the development speed and facilitating easier migration.

• Enhanced Logging: offer better insights during test execution and debugging, making it easier to investigate flaky test

Structure:
The POM structure is organized around distinct page objects for each application UI screen. (Common components, such as the HeaderNavbar, are directly integrated as part of a screen's component when interaction is required. This approach eliminates the need for explicit class extension and allows for the exclusion of the HeaderNavbar in screens where interaction with it is unnecessary.)

Page functions and process:
I've introduced page objects, each designed to encapsulate the elements and interactions specific to their respective pages. Additionally, I've implemented processes such as loginWaitBalance and sendTransaction to efficiently manage common test flows that require interactions across multiple screens.

Processes should be defined for sequences that involve multiple page objects, facilitating broader testing objectives like completing transactions or logging in. These are typically actions that navigate through several screens.

Functions within a class (page object) are best used for actions and verifications that are specific to a single page. This approach promotes the encapsulation and reusability of code for individual UI components or screens, making the tests more modular and maintainable.

3 Migrated Test Cases:
Migrated 3 transaction test cases to the new POM structure, showcasing the improved test architecture and log information. These migrations serve as a POC, demonstrating the effectiveness of POM in our testing environment and provide the base for future migrations.

Additionally, I'm eliminating CSS selectors that aren't robust and replacing them with more stable selectors in this PR.

Related issues

Fixes: #24985
Relates to: #22464

Manual testing steps

Tests should pass on CI. Code should be easy to understand.

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.