Test Automation Scripting Questions

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

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

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

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.

Direct answer

An automated test script is code that exercises the application and checks its behavior without a human performing the steps, in contrast to a manual test case, which is a written set of steps a human follows and judges by eye; the script trades the flexibility and judgment of a human tester for speed, repeatability, and the ability to run the same check thousands of times without fatigue or drift.

Structured elaboration

A manual test case is a document: numbered steps ("navigate to the login page, enter valid credentials, click submit"), an expected result ("the dashboard loads"), and a human who executes it and decides pass or fail, potentially noticing something the steps did not explicitly call out. An automated test script encodes the same steps as executable code, and its "judgment" is limited entirely to whatever assertions the author wrote; it will not notice an unrelated visual glitch a human would catch by eye, but it will run the same check, the same way, in seconds, every single time, forever, without getting bored or skipping a step under deadline pressure.

Concrete tasks commonly automated in a typical web application: a unit test for a pure calculation function (fast, no browser needed, tests logic in isolation); an API contract test that posts to an endpoint and checks the response shape and status code (faster and more stable than driving the same check through the UI); and a simple login end-to-end check that drives a real browser through the actual login flow (slower and more brittle than the other two, but the only one that proves the whole stack, from browser to backend, actually works together).

Worked example

The same login check expressed both ways:

• Manual test case: "1. Open the app. 2. Enter username 'alice' and password 'correct-password'. 3. Click Log In. 4. Verify the dashboard page loads and shows 'Welcome, alice'." A human follows this once per release, or once per bug report, and applies judgment about what "shows Welcome, alice" actually looks like.
• Automated script: a WebDriver-based test that opens the URL, sends the same keystrokes, clicks the same button, and asserts the resulting page title or a specific element's text equals an expected string, run on every single commit rather than once per release, with zero human time cost per run after the one-time cost of writing it.

Trade-offs and pitfalls

The main limitation worth naming honestly: automation only catches what it was explicitly written to check. A human running the manual version above might also notice the page took visibly longer to load than usual, or that a promotional banner overlapped the login button, neither of which the scripted version would ever detect unless someone had thought to assert on load time or layout beforehand. This is why manual and exploratory testing remain valuable alongside automation rather than being fully replaced by it, especially for new features where nobody yet knows what to look for.