Test Automation Scripting Questions

Direct answer

@pytest.mark.parametrize runs the same test body once per row of data you supply, each row becoming its own reported test case with its own pass/fail and its own readable ID in the output, instead of one test that loops internally and reports a single result for all three credential pairs.

Structured elaboration

The pattern has three parts: a parameter list (here, three (username, password, should_succeed) tuples), a test function whose parameters are named exactly to match, and a fixture or setup for anything shared across all rows (here, the object you log in against). The decorator generates one independent test invocation per tuple, so a failure on the invalid-credentials row is reported as test_login[invalid-wrong-False] failing while the two valid-credential rows still show as passed, which is the entire point: a candidate who instead writes for creds in credential_list: assert login(...) gets one pass/fail for the whole loop and loses per-case visibility the moment more than one row is involved.

Worked example

import pytest

class FakeAuthAPI:
    """Stand-in for a real login endpoint/UI so the mechanic can be shown without a server or browser."""
    _valid = {("user1", "pass1"), ("user2", "pass2")}
    def login(self, username, password):
        return (username, password) in self._valid

@pytest.fixture
def api():
    return FakeAuthAPI()

@pytest.mark.parametrize("username, password, should_succeed", [
    ("user1", "pass1", True),
    ("user2", "pass2", True),
    ("invalid", "wrong", False),
])
def test_login(api, username, password, should_succeed):
    result = api.login(username, password)
    assert result is should_succeed

Running it:

$ pytest test_login_parametrize.py -v
collected 3 items

test_login_parametrize.py::test_login[user1-pass1-True] PASSED
test_login_parametrize.py::test_login[user2-pass2-True] PASSED
test_login_parametrize.py::test_login[invalid-wrong-False] PASSED

3 passed in 0.01s

Three independent results, one per credential pair, each individually addressable in a CI report.

The same mechanic works on a trivial pure function too, which is worth knowing as an even more compact way to demonstrate the syntax when the interviewer only wants to see the API, not a login flow:

import pytest

def is_palindrome(s):
    return s == s[::-1]

@pytest.mark.parametrize("s, expected", [
    ("radar", True),
    ("hello", False),
    ("", True),
])
def test_is_palindrome(s, expected):
    assert is_palindrome(s) == expected

$ pytest -v
test_is_palindrome[radar-True] PASSED
test_is_palindrome[hello-False] PASSED
test_is_palindrome[-True] PASSED
3 passed in 0.01s

Trade-offs and pitfalls

The most common mistake is parametrizing a fixture instead of the test when the setup itself needs to vary (use @pytest.fixture(params=[...]) for that, not @pytest.mark.parametrize on the test), which produces confusing double-parametrization if both are used for the same axis. A second pitfall is mutable default state leaking across parametrized runs: if the fixture in this example returned a module-level object instead of a fresh one per test, a mutation in one row (e.g. banning user1 after a failed attempt) could silently affect a later row's result depending on execution order. Finally, once the list of tuples grows past a handful of rows, hardcoding them inline stops scaling. That is the point where the case for pulling data from an external file becomes a genuine data-management decision (how it is stored, generated, and kept in sync with the tests) that goes beyond this one script.

Direct answer

Open the login URL, wait explicitly for the username and password fields to exist before touching them, fill and submit the form, then wait for the resulting page's title to reflect the post-login state before asserting on it, so the test never races the page's own load or redirect timing.

Structured elaboration

The key discipline this exercise tests is using an EXPLICIT wait (WebDriverWait with an expected condition) at every point where the DOM state genuinely depends on timing: once for the username field appearing after the login page loads, and once for the title changing after the redirect following a successful submit. A test that instead used time.sleep(2) in both places would usually pass locally and become flaky in CI the moment the page is slower than the guessed sleep duration; an explicit wait polls until the condition is true (or times out), so it is correct regardless of how fast or slow the page actually is.

Worked example

import pytest
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def do_login(driver, base_url="https://example.com/login"):
    driver.get(base_url)
    wait = WebDriverWait(driver, 10)
    wait.until(EC.presence_of_element_located((By.ID, "username"))).send_keys("testuser")
    driver.find_element(By.ID, "password").send_keys("P@ssw0rd")
    driver.find_element(By.ID, "login-btn").click()
    return wait.until(EC.title_contains("Dashboard"))

@pytest.fixture
def driver():
    from selenium import webdriver
    d = webdriver.Chrome()   # real suite: chromedriver on PATH, as the question assumes
    yield d
    d.quit()

def test_login_direct(driver):
    assert do_login(driver) is True

No browser binary is available in this environment, so the control flow (correct locator usage, correct wait-then-act ordering, correct final assertion) was verified separately against a mocked driver (a realistic title string and a stub find_element) instead of webdriver.Chrome():

from unittest.mock import MagicMock, call

@pytest.fixture
def driver():
    d = MagicMock()
    d.title = "My App - Dashboard"
    d.find_element.return_value = MagicMock()
    return d

def test_login_direct_mocked(driver):
    result = do_login(driver)
    assert result is True
    driver.get.assert_called_once_with("https://example.com/login")
    assert driver.find_element.call_args_list == [
        call(By.ID, "username"),
        call(By.ID, "password"),
        call(By.ID, "login-btn"),
    ]

$ pytest test_direct_login_mocked.py -v
test_login_direct_mocked PASSED
1 passed in 0.11s

This confirms driver.get was called with the right URL exactly once, and find_element was called for username (via the WebDriverWait-guarded lookup), password, and login-btn, in the order the function performs them.

Trade-offs and pitfalls

The most common mistake on this exact exercise is waiting only ONCE, for the username field, and then asserting on the title immediately without a second wait: since the redirect to the dashboard is itself asynchronous, the title assertion can fire before the navigation completes and fail intermittently depending on network/render speed, which is exactly the kind of test that passes on a fast machine and flakes in CI. A second pitfall is hardcoding the 10-second timeout inline on every wait call rather than as one named constant, which becomes a maintenance problem the moment a team decides to tune it suite-wide.

Direct answer

Wrap the "does the table contain this row" check inside an explicit wait that polls until the table has more than zero rows, then search the loaded rows for the target value, structured behind a small page-object-style class for the table so the waiting and searching logic lives in one place rather than being copy-pasted into every test that touches this table.

Structured elaboration

AJAX-loaded content is exactly the case explicit waits exist for: the table element may be present in the DOM immediately (an empty <table> shell) while its rows are still being populated by an async request, so waiting for the ELEMENT to exist is not sufficient; the wait condition needs to check the actual row COUNT. WebDriverWait.until accepts any callable that takes the driver and returns a truthy value once the condition holds, which is exactly what a len(rows) > 0 lambda expresses. Once rows are present, searching them for a specific value is ordinary text matching, not something that needs its own wait, since by that point the data is already loaded.

Worked example

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait

class OrdersTable:
    ROWS = (By.CSS_SELECTOR, "table#orders tbody tr")

    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)

    def wait_until_loaded(self):
        self.wait.until(lambda d: len(d.find_elements(*self.ROWS)) > 0)

    def has_row_with_value(self, value):
        rows = self.driver.find_elements(*self.ROWS)
        return any(value in row.text for row in rows)

@pytest.fixture
def driver():
    from unittest.mock import MagicMock
    d = MagicMock()
    row = MagicMock()
    row.text = "Order #12345 - Shipped"
    d.find_elements.return_value = [row]
    return d

def test_table_contains_order(driver):
    table = OrdersTable(driver)
    table.wait_until_loaded()
    assert table.has_row_with_value("Order #12345") is True

Verified against a mocked driver returning one row whose text is "Order #12345 - Shipped" (no browser is available here, so the driver fixture above stubs find_elements instead of launching a real one):

$ pytest test_ajax_table.py -v
test_table_contains_order PASSED
1 passed in 0.10s

The wait condition (len(rows) > 0) and the search ("Order #12345" in row.text) both executed correctly against the real WebDriverWait/By API, with only the underlying find_elements calls mocked.

Trade-offs and pitfalls

Waiting only for the table ELEMENT to exist (presence_of_element_located on the table itself) rather than for its ROWS to be populated is the single most common mistake on AJAX content: the test passes the wait immediately because the empty table shell is already in the DOM, then fails the search a moment later because the rows have not loaded yet, which reads as a flaky test rather than the wait-condition bug it actually is. A second pitfall is searching row.text for a substring match on data that could plausibly appear in an unrelated row (a customer name that happens to contain the order number's digits, for instance); scoping to a specific column via a more precise CSS selector avoids a false positive once the table has enough rows to make collisions realistic.

Direct answer

A reliable assertion checks a stable, meaningful property of the outcome (the right data appears in the right place, in a form unlikely to change for unrelated reasons) rather than an incidental detail of the current markup or wording, so the test survives cosmetic changes and only fails when the actual behavior it cares about actually breaks.

Structured elaboration

"Fragile" and "robust" are really about what SURFACE an assertion couples itself to. A fragile assertion couples to something that changes for reasons that have nothing to do with correctness: exact visual layout, incidental whitespace, a full page title string that includes a marketing tagline someone will edit next quarter, or a CSS class name a frontend engineer renames during a refactor. A robust assertion couples to the thing the test actually cares about proving: that a specific, stable identifier or piece of application state reflects the successful action, expressed in a form the team has deliberately made stable for testing (a data-test-id, a semantic success message, or the persisted record itself) rather than something that was never meant to be a contract.

Worked example

For "verify a form submission succeeded":

• Fragile example 1: asserting the exact full text of a success banner, e.g. assert banner.text == "Thank you! Your request has been received and a team member will reach out within 2 business days." A copy edit to that sentence breaks the test with zero change in actual behavior.
• Fragile example 2: asserting on a generated, unstable CSS class like .MuiButton-root-482, which a component-library upgrade or a build-hash change can alter without any user-visible difference.
• Robust example 1: asserting on a stable data-test-id="submission-success" element being present, decoupled from whatever the button's styling framework happens to generate.
• Robust example 2: asserting on the actual state change the submission was supposed to cause, for example that a new record now exists (via an API call or a database check) with the submitted values, which proves the FUNCTIONAL outcome regardless of how the confirmation UI is worded or styled.

Trade-offs and pitfalls

The most common mistake is treating "more specific" as automatically "more robust": a very precise assertion (exact copy, exact pixel position) feels thorough but is actually the most fragile kind, since it locks the test to details a product or design team changes routinely. The trade-off on the state-based robust example is that it requires the test to reach past the UI (an API check, a database query) which is more setup than reading the DOM, but that extra setup is exactly what buys freedom from UI wording/styling churn. A middle ground worth naming: asserting on a stable data-test-id gives most of the robustness of a full backend check with much less setup cost, which is why teams that can influence the frontend often standardize on test-only attributes rather than pushing every assertion down to the API layer.

Direct answer

Write the test to CONSUME an existing LoginPage object: the page object owns the locators and the one login(username, password) action, and the test itself only calls that action and asserts on the outcome, with setup/teardown and parametrized credential sets handled at the test level, not inside the page object.

Structured elaboration

A Page Object is a thin wrapper around ONE page's elements and the actions a user can take on it. The dividing line that matters here: the page object exposes a business-meaningful method (login), never raw selectors leaking into the test, and it does not assert anything itself, since assertions belong to the test, not the page. Parameterizing the credential sets is a separate, orthogonal concern from the page object's design: @pytest.mark.parametrize supplies each credential pair to the same test body, and the page object does not need to know or care how many times it gets called.

For setup/teardown, a real test would create a fresh WebDriver session per test (function-scoped fixture, driver.quit() in teardown) so credential sets do not share browser/session state across parametrized runs, which matters because a leftover cookie or "remember me" state from one credential pair could otherwise mask a login bug on the next.

Worked example

import pytest
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    USERNAME = (By.ID, "username")
    PASSWORD = (By.ID, "password")
    SUBMIT = (By.ID, "login-btn")

    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)

    def login(self, username, password):
        self.wait.until(EC.presence_of_element_located(self.USERNAME)).send_keys(username)
        self.driver.find_element(*self.PASSWORD).send_keys(password)
        self.driver.find_element(*self.SUBMIT).click()

@pytest.fixture
def driver():
    from selenium import webdriver
    d = webdriver.Chrome()          # a real suite: one fresh session per test
    yield d
    d.quit()

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow(driver, username, password):
    driver.get("https://example.com/login")
    page = LoginPage(driver)
    page.login(username, password)

No browser binary is available in this environment, so the page object's CONTROL FLOW (not real browser rendering) was verified separately against a mocked driver, asserting the exact sequence of locator calls LoginPage.login makes for each parametrized credential pair:

from unittest.mock import MagicMock

@pytest.fixture
def driver():
    d = MagicMock()
    d.find_element.return_value = MagicMock()
    return d

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow_mocked(driver, username, password):
    page = LoginPage(driver)
    page.login(username, password)
    assert driver.find_element.call_args_list == [
        ((By.ID, "username"),),
        ((By.ID, "password"),),
        ((By.ID, "login-btn"),),
    ]

$ pytest test_login_pom_mock.py -v
test_login_flow_mocked[user1-pass1] PASSED
test_login_flow_mocked[user2-pass2] PASSED
test_login_flow_mocked[invalid-wrongpass] PASSED
3 passed in 0.16s

This confirms, against the real installed Selenium 4 API (By, WebDriverWait, expected_conditions, not hand-typed from memory), that the page object calls find_element(By.ID, "username") (via the WebDriverWait-guarded lookup), find_element(By.ID, "password"), and find_element(By.ID, "login-btn") for every credential pair, in that order, regardless of which pair is under test. (The webdriver.Chrome()-based driver fixture above is what a real suite would run against a live browser; this mocked version is only for verifying the page object's logic here.)

Trade-offs and pitfalls

The most common mistake is putting the assertion inside the page object (e.g. a login_succeeded() method that itself asserts), which makes the page object opinionated about what "success" means for every caller; a page object should expose state (is the dashboard visible?) and let the TEST decide what that state should be for a given credential pair. A second pitfall is sharing one browser session across all three parametrized credential sets to save setup time: that shortcut trades correctness for speed, since a stale session can hide or fake a login result. Finally, WebDriverWait with a hardcoded 10-second timeout is a reasonable default but should be a configurable constant, not repeated as a magic number across every page object in a real suite.