Test Automation Scripting Questions

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

@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

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.

Direct answer

Use new Actions(driver).dragAndDrop(source, target).perform() first, then verify the drop actually took effect (check some observable state change on the target, not just that no exception was thrown); if it silently did nothing, fall back to dispatching a real HTML5 drag event sequence (dragstart/dragover/drop/dragend) via executeScript, since many browsers implement HTML5 drag-and-drop through native OS-level drag events that the Actions API's synthetic mouse-move-based approach does not always trigger correctly.

Structured elaboration

Actions.dragAndDrop under the hood synthesizes a press, a sequence of mouse moves, and a release, which is exactly how NON-HTML5 drag interactions (dragging a slider, resizing a panel) actually work in the browser. Genuine HTML5 drag-and-drop (elements with draggable="true" participating in dragstart/dragover/drop events) is a SEPARATE browser mechanism that some browser/driver combinations do not reliably trigger from synthetic mouse events alone, which is why Actions.dragAndDrop can appear to succeed (no exception, the call completes) while the actual drop event handler never fires and nothing moves.

The fallback constructs and dispatches the real HTML5 drag events directly via JavaScript, using a DataTransfer object (the payload HTML5 drag events carry) and firing dragstart on the source, drop on the target, and dragend on the source, which bypasses the synthetic-mouse-event path entirely and talks to the same event handlers the application's own JavaScript listens for.

Worked example

Actions actions = new Actions(driver);
actions.dragAndDrop(source, target).perform();

// JS fallback, called via driver.executeScript(...) in Java (or execute_script in Python),
// when the native Actions-API drag produces no observable effect:
var dt = new DataTransfer();
arguments[0].dispatchEvent(new DragEvent('dragstart', {dataTransfer: dt}));
arguments[1].dispatchEvent(new DragEvent('drop', {dataTransfer: dt}));
arguments[0].dispatchEvent(new DragEvent('dragend', {dataTransfer: dt}));

No JVM or real browser is available in this environment, so the Java Actions/executeScript calls above are not claimed to have been executed; they are checked against the standard Selenium Java API shape only. What CAN be verified without a browser is the decision logic itself (check an observable count on the target before/after the Actions-API attempt; fall back to the JS event sequence only if unchanged), modeled directly and run under Python with mocked collaborators standing in for the Java calls:

from unittest.mock import Mock

def drag_with_fallback(perform_actions_drag, check_state, js_fallback):
    before = check_state()
    perform_actions_drag()
    after = check_state()
    if after != before:
        return "actions_api_worked"
    js_fallback()
    return "js_fallback_used"

# case 1: Actions API works, observable count changes 0 -> 1
states = iter([0, 1])
result = drag_with_fallback(Mock(), Mock(side_effect=lambda: next(states)), Mock())
print("case 1 (Actions API works, count changed):", result)

# case 2: Actions API silently no-ops, count stays 0 -> 0
js_fallback = Mock()
states = iter([0, 0])
result = drag_with_fallback(Mock(), Mock(side_effect=lambda: next(states)), js_fallback)
print("case 2 (Actions API silently no-ops, JS fallback used):", result)
print("JS fallback called:", js_fallback.called)

Actual output:

case 1 (Actions API works, count changed): actions_api_worked
case 2 (Actions API silently no-ops, JS fallback used): js_fallback_used
JS fallback called: True

This confirms the DECISION structure (only fall back when the observable state genuinely did not change) behaves as claimed. Translating it into Java is a direct one-to-one mapping: before/after become whatever observable count you read from the page, the comparison becomes a plain !before.equals(after), and the two branches call actions.dragAndDrop(...).perform() and the executeScript(...) fallback shown above respectively.

Trade-offs and pitfalls

The most important pitfall this exercise is testing awareness of: Actions.dragAndDrop completing without an exception is NOT evidence the drag succeeded, since the whole failure mode is silent (no error, just no effect); any test using drag-and-drop needs to assert on an actual OBSERVABLE outcome of the drop (an item count, a moved element's new position, a class change) rather than only checking that .perform() did not throw. A second pitfall with the JS fallback itself: dispatching synthetic DragEvents bypasses the browser's real user-input path entirely, so a test that only ever exercises the JS fallback risks never proving a genuine user COULD perform this drag with a real mouse; keeping the Actions-API attempt as the first try (and only falling back when it demonstrably fails) preserves that signal wherever the browser actually supports it.

Direct answer

ElementNotInteractableException almost always means the element exists in the DOM but is not actually clickable right now: it may be covered by another element (a modal, a sticky header, a loading overlay), still animating into place, off-screen, or the DOM reference itself is stale because the page re-rendered; the fix is a layered escalation, wait for real interactability, scroll it into view, retry, and only fall back to a JavaScript click as a last resort since a JS click bypasses the same visibility checks a real user's click would be blocked by.

Structured elaboration

Four likely root causes, roughly in order of frequency: (1) overlay/covering element, something else (a cookie banner, a fixed nav bar, a modal backdrop) is currently on top of the target in z-order, so the browser's real click-target resolution lands on the covering element instead; (2) timing, the click fires before an in-progress CSS transition/animation finishes moving the element into its final position; (3) stale element, the DOM node the test grabbed a reference to was removed and replaced by a fresh render (common after an AJAX update), so operating on the old reference throws even though a NEW, interactable element with the same content now exists; (4) off-screen/scroll position, the element exists and is otherwise fine but is outside the current viewport.

A layered fix mirrors that diagnosis order: first, use an explicit wait for element_to_be_clickable rather than merely presence_of_element_located, since presence in the DOM does not mean interactable; second, scroll the element into view before clicking; third, if the element reference itself might be stale, re-locate it fresh rather than reusing an old handle; and only as a last resort, use a JavaScript-executed click, which clicks the DOM node directly regardless of visibility/overlay state, precisely because that bypass is also what makes it risky: a JS click can "pass" a test even when a real user genuinely could not have clicked that element, silently hiding a real UX bug.

Worked example

from selenium.common.exceptions import ElementNotInteractableException, StaleElementReferenceException
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def robust_click(driver, locator, timeout=10):
    """locator is a (By, value) tuple, not a resolved element, so a stale reference
    can be RE-LOCATED rather than reused."""
    try:
        element = WebDriverWait(driver, timeout).until(EC.element_to_be_clickable(locator))
    except StaleElementReferenceException:
        element = driver.find_element(*locator)

    try:
        element.click()
        return "normal_click"
    except (ElementNotInteractableException, StaleElementReferenceException):
        element = driver.find_element(*locator)  # re-locate: the old handle may be stale
        driver.execute_script("arguments[0].scrollIntoView({block: 'center'});", element)
        try:
            element.click()
            return "click_after_scroll"
        except (ElementNotInteractableException, StaleElementReferenceException):
            element = driver.find_element(*locator)
            driver.execute_script("arguments[0].click();", element)
            return "js_click_fallback"


from unittest.mock import MagicMock

driver = MagicMock()
locator = ("id", "submit-btn")

# case 1: clickable immediately, wait succeeds, real click succeeds
el1 = MagicMock()
driver.find_element.return_value = el1
WebDriverWait.until = lambda self, method, message="": el1
print("case 1 (clickable immediately):", robust_click(driver, locator))

# case 2: real click blocked once (e.g. overlay), succeeds after scroll
el2 = MagicMock()
el2.click.side_effect = [ElementNotInteractableException(), None]
driver.find_element.return_value = el2
WebDriverWait.until = lambda self, method, message="": el2
print("case 2 (needs scroll then succeeds):", robust_click(driver, locator))

# case 3: element is stale on every click attempt, forcing re-locate down to the JS-click fallback
el3 = MagicMock()
el3.click.side_effect = StaleElementReferenceException()
driver.find_element.return_value = el3
WebDriverWait.until = lambda self, method, message="": el3
print("case 3 (stale element, forces JS click fallback):", robust_click(driver, locator))

Running it:

case 1 (clickable immediately): normal_click
case 2 (needs scroll then succeeds): click_after_scroll
case 3 (stale element, forces JS click fallback): js_click_fallback

All three branches were exercised and returned the expected outcome, and, unlike a version that only reacts to ElementNotInteractableException, this one implements ALL four fixes the question asked for: an explicit wait for element_to_be_clickable (not just presence), re-locating the element by its locator (not reusing a possibly-stale handle) on both the initial wait and each retry, scrolling into view, and the JavaScript click strictly as the last resort.

Trade-offs and pitfalls

The most consequential pitfall is reaching for the JavaScript-click fallback FIRST instead of last: it makes the flaky test "pass" reliably while masking a real accessibility/UX defect (a genuine user with a mouse cannot click something covered by an overlay either), so a fix that always JS-clicks is treating the symptom, not confirming the product actually works. A second pitfall is re-locating the element on every retry without checking whether the ORIGINAL failure was really about staleness versus visibility, since blindly re-locating an element that was simply covered by an overlay does nothing to address the overlay itself and the retry will fail the same way.