Programming for Test Automation Questions

Direct answer

Polymorphism means code can call the same method on objects of different concrete types and get type-appropriate behavior, without the caller knowing or caring which concrete type it is holding. In a test context, the practical payoff is substitutability: if the code under test depends only on an interface (or abstract base type), a test harness can hand it a fake or stub implementation that satisfies the same contract, with no change to the code under test.

Structured elaboration

The mechanism is the same in Python and Java, just with different enforcement:

• Java enforces the contract at compile time through an interface or abstract class. Any class implementing that interface is interchangeable wherever the interface type is used.
• Python relies on structural typing (duck typing): any object with a matching send(message) method works, whether or not it formally inherits from a common base. Python also supports abc.ABC with @abstractmethod when you want the contract enforced explicitly rather than left implicit.

Why this specifically helps testing: if a function or class depends on a concrete SmtpNotificationSender directly, a test either has to actually send an email (slow, flaky, has side effects) or reach for a mocking library to intercept calls on that concrete class. If the function instead depends on the interface NotificationSender, the test can construct a small, explicit FakeNotificationSender that implements the same interface with in-memory state, and pass it in directly. No mocking framework is required, the fake's behavior is fully visible in the test file, and the production code never needs to know a fake exists.

Worked example

Python:

from abc import ABC, abstractmethod


class NotificationSender(ABC):
    """Common interface both the real sender and a test fake implement."""

    @abstractmethod
    def send(self, message: str) -> bool:
        """Return True on success."""


class SmtpNotificationSender(NotificationSender):
    """The real implementation used in production."""

    def send(self, message: str) -> bool:
        print(f"[SMTP] sending: {message}")
        return True


class FakeNotificationSender(NotificationSender):
    """A test double: same interface, no real network I/O."""

    def __init__(self):
        self.sent = []

    def send(self, message: str) -> bool:
        self.sent.append(message)
        return True


def notify_on_failure(sender: NotificationSender, test_name: str) -> bool:
    """Depends only on the NotificationSender interface, so a harness can
    substitute FakeNotificationSender without touching this function."""
    return sender.send(f"{test_name} failed")


def test_notify_on_failure_uses_fake_sender():
    fake = FakeNotificationSender()
    result = notify_on_failure(fake, "test_login_flow")
    assert result is True
    assert fake.sent == ["test_login_flow failed"]
    print("test_notify_on_failure_uses_fake_sender: PASS")


test_notify_on_failure_uses_fake_sender()

Output:

test_notify_on_failure_uses_fake_sender: PASS

Java (compiled and run with a real JDK, not merely written):

interface NotificationSender {
    boolean send(String message);
}

class SmtpNotificationSender implements NotificationSender {
    public boolean send(String message) {
        System.out.println("[SMTP] sending: " + message);
        return true;
    }
}

class FakeNotificationSender implements NotificationSender {
    public final java.util.List<String> sent = new java.util.ArrayList<>();
    public boolean send(String message) {
        sent.add(message);
        return true;
    }
}

class NotifierUnderTest {
    static boolean notifyOnFailure(NotificationSender sender, String testName) {
        return sender.send(testName + " failed");
    }
}

public class NotificationDemo {
    public static void main(String[] args) {
        FakeNotificationSender fake = new FakeNotificationSender();
        boolean result = NotifierUnderTest.notifyOnFailure(fake, "test_login_flow");
        if (result != true) throw new AssertionError("expected true");
        if (!fake.sent.equals(java.util.List.of("test_login_flow failed"))) {
            throw new AssertionError("unexpected sent list: " + fake.sent);
        }
        System.out.println("java test_notifyOnFailure_usesFakeSender: PASS");
    }
}

Output:

java test_notifyOnFailure_usesFakeSender: PASS

Trade-offs and pitfalls

• Over-abstraction is a real cost. Introducing an interface purely so a test can fake it, for a dependency with no real variation, adds an indirection layer future readers have to trace through. Reserve this for dependencies that are genuinely slow, flaky, or side-effecting (network calls, disks, clocks), not for pure, fast, deterministic logic that a test can simply call directly.
• A fake is not a mock. A hand-written fake like FakeNotificationSender encodes real (if simplified) behavior and is easy to read in the test file. A mocking-library mock instead records arbitrary call expectations, which can let a test pass even when the mocked calls no longer match how the code actually behaves. Prefer a fake when the dependency's contract is small and stable.
• Duck typing in Python means the interface is a convention, not an enforcement, unless you use ABC. A FakeNotificationSender that quietly stops implementing send correctly will not be caught until the test that exercises it runs, whereas Java's compiler catches a broken implementation immediately.

Direct answer

The hashing-and-equality contract requires that two objects considered equal (equals/__eq__) must produce the same hash (hashCode/__hash__), and that an object's hash must not change while it is stored as a key in a hash-based container. The most common violation is using a mutable field in __hash__/equals and then mutating that field after the object has already been inserted, which silently makes the object unfindable, not merely slow to find.

Structured elaboration

When an object is inserted into a hash table, the container computes its hash once and uses that value to choose a bucket. If the object's hash later changes (because a field it depends on was mutated), the object is still physically sitting in the OLD bucket, but any future lookup computes the NEW hash and looks in a different bucket entirely. The object is not corrupted or lost from memory; it becomes permanently unreachable by key, which is a uniquely dangerous kind of bug because there is no exception, no warning, and no crash: if key in my_set simply and silently returns false for a key you know you inserted.

A concrete test strategy to catch this before it ships, rather than discovering it as an intermittent production bug: assert that an object's hash is stable across any operation your test suite performs on it. Concretely, record hash(obj) immediately after construction, run whatever operation is under test, and assert hash(obj) is unchanged afterward. This test is generic (it works for any key type, not just one you already suspect) and catches the violation at the moment the mutation happens, rather than waiting for a lookup to fail later and having to trace the failure back to an unrelated mutation.

Worked example

Verified:

class BadMutableKey:
    """Hashes on a mutable field -- the textbook way to break the contract."""
    def __init__(self, name):
        self.name = name

    def __hash__(self):
        return hash(self.name)

    def __eq__(self, other):
        return isinstance(other, BadMutableKey) and self.name == other.name


key = BadMutableKey("alpha")
s = {key}
assert key in s  # found before mutation

key.name = "beta"  # mutate the field __hash__ depends on
found_by_identity = key in s
print("after mutating name alpha->beta, key in s (same object reference):", found_by_identity)
assert found_by_identity is False

Output:

after mutating name alpha->beta, key in s (same object reference): False

The object is unfindable by its own reference immediately after the mutation, confirming the violation.

The generic test strategy, also executed:

def assert_hash_is_stable(obj, after_operation):
    h_before = hash(obj)
    after_operation(obj)
    h_after = hash(obj)
    assert h_before == h_after, (
        f"hash changed from {h_before} to {h_after} after an operation; this object "
        f"violates the hash/equality contract if used as a map/set key while mutable"
    )

try:
    unstable_key = BadMutableKey("gamma")
    assert_hash_is_stable(unstable_key, lambda k: setattr(k, "name", "delta"))
except AssertionError as e:
    print("hash-stability probe caught the violation:", e)

Output:

hash-stability probe caught the violation: hash changed from 7431044713371916513 to 5261283214583879591 after an operation; this object violates the hash/equality contract if used as a map/set key while mutable

The fix (Java's equivalent is a class whose hashCode/equals fields are declared final so they cannot be reassigned after construction):

class SafeImmutableKey:
    __slots__ = ("_name",)
    def __init__(self, name):
        object.__setattr__(self, "_name", name)
    @property
    def name(self):
        return self._name
    def __hash__(self):
        return hash(self._name)
    def __eq__(self, other):
        return isinstance(other, SafeImmutableKey) and self._name == other._name
    def __setattr__(self, key, value):
        raise AttributeError("SafeImmutableKey is immutable; construct a new instance instead")

Verified:

safe_key = SafeImmutableKey("alpha")
safe_set = {safe_key}
assert safe_key in safe_set
try:
    safe_key.name = "beta"
    print("ERROR: mutation should have raised")
except AttributeError as e:
    print("SafeImmutableKey mutation raised as expected:", e)
assert safe_key in safe_set
print("SafeImmutableKey remains findable after attempted mutation")

Output:

SafeImmutableKey mutation raised as expected: SafeImmutableKey is immutable; construct a new instance instead
SafeImmutableKey remains findable after attempted mutation

Attempting key.name = "beta" on a SafeImmutableKey raises AttributeError immediately, and the key remains findable in the set because it can never drift out of its bucket in the first place.

Trade-offs and pitfalls

• This bug is uniquely hard to trace in production because the symptom (a lookup that should succeed silently returns "not found") looks identical to "the item was never inserted," sending debugging effort toward the insertion path instead of the mutation that actually caused it.
• Making a key type immutable is the most robust fix, but is not always possible for objects with a legitimate reason to change; when a mutable object must be used as a key, the discipline has to be enforced by convention (never mutate a hash-affecting field while the object is stored) and caught by exactly the kind of hash-stability test shown above.
• In Java, records (record types, since Java 16) enforce this by construction the same way SafeImmutableKey's __slots__ plus a blocked __setattr__ do here: all fields are final, so hashCode/equals derived from them cannot drift after construction.

Direct answer

Java's checked exceptions force every caller, at compile time, to either handle or explicitly re-declare a failure; unchecked exceptions (subclasses of RuntimeException) carry no such obligation. Use a checked exception for a condition a well-written caller is expected to plan for, such as a transient I/O failure a retry loop should catch. Use an unchecked exception for a programmer error, such as an invalid argument, where forcing every caller to catch it everywhere would just be noise around a bug that should be fixed in the code, not handled at runtime.

Structured elaboration

The distinction is about who is expected to react, and how:

Python does not have a checked/unchecked split enforced by the language; the same design intent still applies through which exception type you catch. A try/except TransientConnectException block that does not also catch ValueError is the Python equivalent of "only the checked, expected category gets retried."

How this affects test reliability specifically: a retry-loop test needs to prove two distinct things, not one. It must show that the expected, checked-style failure is retried and eventually succeeds (or fails clearly once retries are exhausted), and separately that a programmer-error-style failure is not silently swallowed by the same retry loop, since retrying a logic error just delays the same guaranteed failure and hides the real bug behind a slower, more confusing stack trace.

Worked example

Java (compiled and run with a real JDK):

import java.io.IOException;

class InvalidTimeoutException extends RuntimeException {
    InvalidTimeoutException(String msg) { super(msg); }
}

class TransientConnectException extends IOException {
    TransientConnectException(String msg) { super(msg); }
}

class FlakyConnector {
    private int callCount = 0;

    boolean connect(int timeoutMs) throws TransientConnectException {
        if (timeoutMs < 0) {
            throw new InvalidTimeoutException("timeoutMs must be >= 0, got " + timeoutMs);
        }
        callCount++;
        if (callCount < 3) {
            throw new TransientConnectException("connection attempt " + callCount + " timed out");
        }
        return true;
    }
}

public class ExceptionDemo {
    static boolean connectWithRetry(FlakyConnector connector, int timeoutMs, int maxAttempts) {
        int attempt = 0;
        while (true) {
            attempt++;
            try {
                return connector.connect(timeoutMs);
            } catch (TransientConnectException e) {
                if (attempt >= maxAttempts) {
                    throw new RuntimeException("gave up after " + attempt + " attempts", e);
                }
            }
        }
    }

    public static void main(String[] args) {
        FlakyConnector connector = new FlakyConnector();
        boolean result = connectWithRetry(connector, 1000, 5);
        if (!result) throw new AssertionError("expected eventual success");
        System.out.println("test_retry_succeeds_after_transient_failures: PASS");

        FlakyConnector connector2 = new FlakyConnector();
        try {
            connectWithRetry(connector2, 1000, 2);
            throw new AssertionError("expected retry exhaustion to raise");
        } catch (RuntimeException e) {
            System.out.println("test_retry_exhausted_raises_clearly: caught -> " + e.getMessage());
        }

        FlakyConnector connector3 = new FlakyConnector();
        try {
            connectWithRetry(connector3, -5, 5);
            throw new AssertionError("expected InvalidTimeoutException to propagate");
        } catch (InvalidTimeoutException e) {
            System.out.println("test_invalid_timeout_is_not_retried: caught -> " + e.getMessage());
        }
    }
}

Output:

test_retry_succeeds_after_transient_failures: PASS
test_retry_exhausted_raises_clearly: caught -> gave up after 2 attempts
test_invalid_timeout_is_not_retried: caught -> timeoutMs must be >= 0, got -5

Trade-offs and pitfalls

• Checked-exception fatigue is a real, widely-cited Java criticism: overusing checked exceptions for conditions that are not truly recoverable (or that every caller just rethrows) produces boilerplate try/catch or throws clauses everywhere with no benefit. Reserve checked exceptions for conditions a caller genuinely has a different, better response to.
• Catching too broadly defeats the whole point. A catch (Exception e) around a retry loop would also swallow InvalidTimeoutException, silently retrying a bug instead of surfacing it. The test above specifically checks that only the intended exception type is retried.
• In Python, the discipline has to be self-enforced by catching the narrowest reasonable type (a custom TransientConnectException, not a bare except Exception), since there is no compiler to force the distinction.

Direct answer

Choose the collection by the operation you need to be fast, not by habit: an array/list for ordered, indexed access; a set for membership and uniqueness; a map/dictionary for key-based lookup; a queue for first-in-first-out processing order; a priority queue when the next item to process is determined by a score rather than arrival order.

Structured elaboration

The trade-off that actually shows up in a coding round is almost always membership/lookup speed versus ordering guarantees: a list gives you order for free but costs O(n) to check membership; a set or map gives O(1) membership/lookup but, in Java's HashSet/HashMap, gives up insertion order entirely (Python's set/dict also do not guarantee insertion order for set, though dict has guaranteed insertion order since Python 3.7, which is a genuine language difference worth naming explicitly if asked).

On the Python-versus-Java angle specifically, for deduplicating test inputs or tracking already-seen records: both languages reach for a hash-based set, but the practical difference is what you get "for free" alongside it. Python's dict preserves insertion order as a language guarantee, so a dict doubling as an ordered, deduplicated record of "first-seen order" needs no extra structure. Java's HashMap makes no such guarantee, so the equivalent pattern in Java is LinkedHashMap, which explicitly layers insertion-order tracking on top of hash-based lookup; reaching for plain HashMap when order matters is a common Java mistake.

Worked example

A compact illustration of the ordering difference:

# Python: dict preserves insertion order (language guarantee since 3.7)
seen = {}
for record in ["b", "a", "b", "c", "a"]:
    seen.setdefault(record, True)
print("python dict insertion order preserved:", list(seen.keys()))
assert list(seen.keys()) == ["b", "a", "c"]

Output:

python dict insertion order preserved: ['b', 'a', 'c']

// Java: plain HashMap makes no ordering guarantee; LinkedHashMap does.
import java.util.LinkedHashMap;
import java.util.Map;

public class OrderDemo {
    public static void main(String[] args) {
        Map<String, Boolean> seen = new LinkedHashMap<>();
        for (String record : new String[]{"b", "a", "b", "c", "a"}) {
            seen.putIfAbsent(record, true);
        }
        System.out.println("java LinkedHashMap insertion order preserved: " + seen.keySet());
        if (!seen.keySet().toString().equals("[b, a, c]")) {
            throw new AssertionError("expected insertion order [b, a, c], got " + seen.keySet());
        }
        System.out.println("PASS");
    }
}

Output (compiled and run with a real JDK):

java LinkedHashMap insertion order preserved: [b, a, c]
PASS

Trade-offs and pitfalls

• Reaching for a list and doing repeated in checks is the most common interview miss: it works on small inputs and silently becomes an O(n^2) bottleneck on large test suites, exactly the kind of bug that only shows up once a suite grows past a few hundred tests.
• Priority queues are frequently the right answer to "how do you decide what to run first", but are frequently under-used in favor of manually sorting the whole list up front, which is more expensive when the run order needs to adapt as new information (a new failure) arrives mid-run.
• Do not reach for HashMap/HashSet in Java when order matters, and do not assume Python's set preserves order the way dict does; conflating the two is a common source of subtle, hard-to-reproduce ordering bugs in test-result aggregation code.

Direct answer

Use a generator that opens the file once and yields non-empty lines as it reads, so memory use stays proportional to one line at a time rather than the whole file; extending it to batches and an optional deterministic shuffle only changes how many lines are buffered before yielding, not the fundamentally streamed read.

Structured elaboration

The core pattern is: open the file inside the generator (so the file handle's lifetime is tied to the generator's), iterate line by line (the file object itself is already an iterator that reads incrementally, never the whole file at once), filter out empty/whitespace-only lines, and yield each surviving line immediately rather than accumulating a list.

Extending this to fixed-size batches with an optional deterministic shuffle adds exactly one more piece of state: a buffer list capped at batch_size. Once the buffer reaches that size, optionally shuffle it (using a random.Random(seed) instance local to the call, for the same reason a seeded deterministic sampler should use an isolated generator instance rather than the global random module) and yield the whole batch, then start a new empty buffer. The memory footprint is now bounded by batch_size, not by file size, which is the same guarantee as the single-line version, just at a coarser granularity.

Worked example

Verified:

import random

def stream_first_n_nonempty_lines(path, n):
    if n <= 0:
        return
    count = 0
    with open(path, "r", encoding="utf-8") as f:
        for raw_line in f:
            line = raw_line.rstrip("\n")
            if line.strip() == "":
                continue
            yield line
            count += 1
            if count >= n:
                return

def stream_batches(path, batch_size, shuffle=False, seed=None):
    rng = random.Random(seed) if shuffle else None
    batch = []
    with open(path, "r", encoding="utf-8") as f:
        for raw_line in f:
            line = raw_line.rstrip("\n")
            if line.strip() == "":
                continue
            batch.append(line)
            if len(batch) == batch_size:
                if shuffle:
                    rng.shuffle(batch)
                yield batch
                batch = []
    if batch:
        if shuffle:
            rng.shuffle(batch)
        yield batch

# basic streaming, and fewer-lines-than-requested
import tempfile, os
def _write(content):
    tf = tempfile.NamedTemporaryFile(delete=False, mode="w", encoding="utf-8")
    tf.write(content); tf.close()
    return tf.name

path = _write("first\n\n second \n\nthird\n")
assert list(stream_first_n_nonempty_lines(path, 2)) == ["first", " second "]
os.unlink(path)
print("basic streaming: PASS")

# batching partitions correctly
lines = "\n".join(f"line{i}" for i in range(10)) + "\n"
path = _write(lines)
batches = list(stream_batches(path, batch_size=3, shuffle=False))
assert [len(b) for b in batches] == [3, 3, 3, 1]
assert sum(batches, []) == [f"line{i}" for i in range(10)]
os.unlink(path)
print("batching test: batch sizes", [len(b) for b in batches])

# deterministic shuffle given a seed
lines = "\n".join(f"line{i}" for i in range(9)) + "\n"
path = _write(lines)
run1 = list(stream_batches(path, batch_size=9, shuffle=True, seed=42))
run2 = list(stream_batches(path, batch_size=9, shuffle=True, seed=42))
assert run1 == run2
os.unlink(path)
print("deterministic-shuffle test: seed=42 both runs ->", run1[0])

Output:

basic streaming: PASS
batching test: batch sizes [3, 3, 3, 1]
deterministic-shuffle test: seed=42 both runs -> ['line3', 'line6', 'line7', 'line4', 'line8', 'line2', 'line5', 'line0', 'line1']

Trade-offs and pitfalls

• Shuffling within a batch is not the same as shuffling across the whole file. This design only randomizes the order of lines within each fixed-size batch, so the first batch's lines can never end up in the last batch. If a caller needs a global shuffle, this streamed approach is the wrong tool; that requires either loading everything into memory or a reservoir-style algorithm.
• A common mistake is seeding once outside the generator and reusing the same random.Random instance across multiple calls, which makes the second call's shuffle depend on how many random numbers the first call already consumed; instantiating a fresh random.Random(seed) per call, as done here, avoids that.
• rstrip('\n') intentionally preserves other whitespace (a line that is only internal spaces around real content keeps it); only a line that is empty or all-whitespace after stripping is treated as "empty" and skipped, which the basic-streaming test's " second " case (leading/trailing spaces preserved) specifically checks.