Build a Maintainable Learning Portal Selenium Suite

1. Maven project setup and first test

Scenario: you are building a real, local automated test suite for a small demo web app (any simple static site or local dev server you control) -- entirely on your own machine. Initialize a Maven project with selenium-java and junit-jupiter dependencies, configure WebDriverManager (or manually manage a matching driver), and write a first JUnit test that opens a real browser, navigates to a page, and asserts an element's text using an explicit wait.

• mvn test runs a real Selenium test that launches an actual browser
• The test uses WebDriverWait with an explicit ExpectedCondition, not Thread.sleep
• The driver is properly quit in an @AfterEach (or equivalent) so no browser process is left running

2. A realistic multi-page workflow

Automate a multi-step workflow spanning at least 3 pages of your demo app (for example: search, view a result, submit a form) using accessible, stable locator strategies (id, name, or a stable data attribute over a brittle absolute XPath) and explicit waits at every step where content loads asynchronously. Include at least one assertion on an error or validation state.

• The workflow spans at least 3 distinct pages/states in a single test
• Every wait is explicit or fluent, never a fixed Thread.sleep
• At least one assertion covers an error or validation state, not only the happy path

3. Page objects and a reusable component object

Refactor the workflow from Milestone 2 into page object classes (one per page, encapsulating that page's locators and actions behind clearly named methods) and extract at least one UI piece that appears on multiple pages (like a navigation bar) into a separate, reusable component object that the page objects hold an instance of.

• At least 3 page object classes exist, each owning only its own page's locators and actions
• At least 1 component object exists for a UI piece reused across multiple pages, held by the page objects that embed it
• The test from Milestone 2 is rewritten to use only page/component objects, with no locators inline in the test itself

4. JUnit parameterized tests and the Actions API

Convert at least one test into a JUnit 5 @ParameterizedTest covering at least 3 distinct input scenarios (for example, 3 different search terms or form inputs, including at least one invalid one). Add a test using the Actions API for a non-trivial interaction (a hover-triggered menu, a drag action, or a right-click, depending on your demo app).

• At least one @ParameterizedTest exists, covering 3 or more distinct scenarios via @ValueSource, @CsvSource, or @MethodSource
• At least one test uses the Actions API for an interaction plain click()/sendKeys() can't express
• All parameterized scenarios pass

5. Failure diagnosis and CI execution

Intentionally introduce a timing issue (remove an explicit wait) to reproduce a real stale-element or timing failure, capture a screenshot at the point of failure, diagnose and fix the root cause, and confirm the suite passes reliably across several consecutive runs. Add a GitHub Actions workflow that installs a JDK, runs mvn test with a headless browser, and publishes the test report.

• A real, intentionally reproduced failure was diagnosed to its actual root cause (not just retried until it passed)
• The suite passes reliably across at least 3 consecutive local runs after the fix
• A CI workflow file exists that sets up Java, runs the suite headlessly, and publishes the test results