Name: Page Object Model and Framework Design
Availability: InStock

Ten questions on the decisions this course made, and why. Each answer comes with a short explanation.

1. A developer renames the login button's id from submit to login-button. In a suite built with page objects, what should need to change?

Every test that logs in One locator in LoginPage The test data files for each environment

Locators live in exactly one place, the page object. If tests had to change, locator knowledge has leaked out of the page object layer.

2. On the practice site, #error is in the DOM from page load with opacity 0. In Playwright, await expect(page.locator('#error')).toBeVisible() right after goto() will...

Fail, because the element is transparent Time out waiting for the element to appear Pass, because Playwright treats opacity:0 as visible

Playwright's visibility check ignores opacity, so the assertion passes without any login attempt. The page object encodes the real meaning with #error.show. Selenium's isDisplayed() returns false for the same element.

3. Which check is acceptable inside a page object according to the Selenium documentation?

Verifying, while the object is created, that the right page has loaded Asserting that the welcome message contains the user's name Asserting that an error message matches the expected text

The docs say page objects should never make verifications, except checking that the page and critical elements loaded correctly, done at instantiation. Outcome checks belong in the test.

4. A login can succeed, or fail with an error on the same page. What is the cleanest page object API for that?

One login() method returning Object, cast by the test loginAs() returning LoggedInPage and loginExpectingError() returning LoginPage One login(boolean expectSuccess) method that asserts the outcome

Separate methods make each expected outcome explicit in the test and give it a precise return type. A boolean flag plus internal assertions hides the expectation in the page object.

5. By.linkText("Practice") finds nothing in the practice site's menu, while the DOM text is "Practice". Why?

The link is inside an iframe linkText only works on buttons CSS text-transform renders it as "PRACTICE", and Selenium matches the rendered text

Selenium's link text uses what is rendered. Matching on DOM text (an XPath normalize-space() predicate, or Playwright's accessible name) keeps the locator independent of styling.

6. What is the main practical problem with @FindBy fields and PageFactory.initElements(driver, this)?

Waiting is hidden in the locator factory and limited to presence, so explicit visibility or clickability waits are still needed It was removed in Selenium 4 and no longer compiles Proxy fields always throw StaleElementReferenceException

Page Factory still ships and is not deprecated, but its docs are in the Legacy section. Proxies re-find elements on each call; staleness only appears with @CacheLookup.

7. A TestNG class stores WebDriver driver in an instance field set in @BeforeMethod, and the suite runs with parallel="methods". What happens?

Each method gets its own class instance, so it works Threads overwrite each other's driver: tests drive the wrong browser, hit quit sessions, and leak browsers TestNG detects the shared field and runs the methods sequentially

TestNG shares one instance across threads. A ThreadLocal driver, cleared with remove() after quit(), gives every thread its own browser.

8. With pytest-xdist (pytest -n 4), a fixture has scope="session". How often does it run?

Once for the whole run Once per test Once per worker process

xdist workers are separate processes, each with its own session. That isolation is why Python needs no ThreadLocal, and why "run once" setup must be designed for several workers.

9. A Playwright test fails, then passes on retry. Which setting makes the run fail anyway, so the flakiness is not hidden?

failOnFlakyTests: true (or --fail-on-flaky-tests) trace: 'on-first-retry' retries: 0 in the test file

Playwright marks such tests "flaky", and failOnFlakyTests turns that into a failed run. Trace settings only control evidence; they do not change the result.

10. Your page objects need to run on a remote grid instead of local browsers. With the framework from this course, what changes?

Every page object gets a remote-aware constructor Only config: the driver factory, pytest fixture or Playwright project creates a remote session Tests must switch from By locators to XPath

Page objects only depend on a WebDriver or Page. Where that browser runs is decided in one place in the framework layer, which is the point of separating the layers.

Next, put the framework to work: our Selenium with Java and TestNG course goes deeper into the runner used in chapters 01-07, and the Playwright Test documentation shows the full configuration for running these specs on TestingBot.

Knowledge check

You finished Page Object Model and Framework Design