Assertions and Behavior Verification Questions

Choosing what to assert and how to verify behavior meaningfully. Covers assertion strategy, verifying observable behavior over implementation detail, avoiding weak or over-specified assertions, and using assertion libraries effectively. Emphasizes assertions that fail for the right reasons and give a clear diagnosis.

MediumTechnical

71 practiced

An API returns a list of items but the backend does not guarantee ordering. In Python (pytest), show how you would write assertions that verify the API response contains exactly the set of expected items regardless of order and also validate per-item attributes. Provide concise example code or pseudo-code.

Sample Answer

Approach Compare collections independent of order by converting to sets or Counters. For per-item attribute checks, index items by a stable key (e.g., id) and assert attributes. Example pytest code pythonimport pytest from collections import Counter # sample response from API response_items = [ {"id": 1, "name": "alpha", "active": True}, {"id": 2, "name": "beta", "active": False}, ] expected_items = [ {"id": 2, "name": "beta", "active": False}, {"id": 1, "name": "alpha", "active": True}, ] def normalize_for_set(item): # tuple of sorted key-values ensures deterministic hashable representation return tuple(sorted(item.items())) def test_items_exact_set_and_attributes(): # 1) exact set regardless of order (handles uniqueness) assert set(map(normalize_for_set, response_items)) == set(map(normalize_for_set, expected_items)) # 2) If duplicates allowed, use Counter assert Counter(map(normalize_for_set, response_items)) == Counter(map(normalize_for_set, expected_items)) # 3) Per-item attribute checks by id resp_by_id = {item["id"]: item for item in response_items} for exp in expected_items: rid = exp["id"] assert rid in resp_by_id, f"missing id {rid}" resp = resp_by_id[rid] # check specific attributes assert resp["name"] == exp["name"] assert resp["active"] is exp["active"] Notes Use id as key only if it's unique; otherwise include compound key. normalize_for_set works for simple JSON scalars; for nested structures consider recursive normalization.

EasyTechnical

112 practiced

What logging and assertion practices should automated tests follow to maximize diagnosability when failures occur? Provide examples of useful structured log content, what context to include (e.g., test id, request/response), and guidance on assertion granularity and failure messages.

Sample Answer

Brief approach Focus logs and assertions so a failure gives immediate root-cause clues: who ran the test, what inputs were used, system state, and expected vs actual. Useful structured log content Always emit structured (JSON) logs with these fields: json{ "timestamp":"2026-03-02T12:00:00Z", "test_id":"checkout_e2e_42", "suite":"checkout_e2e", "env":"staging", "step":"place_order_request", "request":{"cart_id":"c123","total":49.99}, "response":{"status":500,"body":"Internal Server Error"}, "run_id":"ci-5678", "node":"agent-3", "duration_ms":342 } Include correlation ids (run_id, trace_id), environment, and agent/host. Log stack traces only when relevant. Assertion granularity & messages Assert one logical outcome per assertion. Prefer multiple specific assertions over one compound assert. Write failure messages showing expected and actual, plus context: python# example assert resp.status_code == 200, f"Expected 200 OK for test_id={test_id}, got {resp.status_code}, body={resp.text}" For complex objects, diff key fields rather than entire blobs. Best practices Log inputs before action and responses after. Capture snapshots (DB queries, metrics) on failure. Use levels (INFO, DEBUG, ERROR) and avoid noisy logs in passing runs. Make assertions deterministic and idempotent. These practices speed diagnosis and reduce back-and-forth with developers.

MediumTechnical

73 practiced

Explain the difference between soft assertions (collecting multiple failures in a test) and hard assertions (failing immediately). When is it appropriate to use soft assertions in UI tests? Show how you would implement soft assertions in pytest or TestNG and discuss trade-offs regarding debugging and flakiness.

Sample Answer

Difference: soft vs hard assertions Hard assertion: stops the test immediately when a check fails (fail-fast). Use when further steps are meaningless or dangerous (e.g., login failed but test assumes authenticated state). Soft assertion: records failures and continues executing the test, reporting all failures at the end. Useful to collect multiple independent verification points in one run. When to use soft assertions in UI tests Use when multiple independent UI elements need verification on the same page (layout, text, visibility) so you get a full picture in one run. Avoid for prerequisite checks (e.g., page failed to load) where continuing yields noise or exceptions. Helpful in exploratory/regression runs to reduce cycles and give developers more context. Example — pytest (using soft-assert helper) python# pytest example using a simple collector class SoftAssert: def __init__(self): self.errors = [] def check(self, expr, msg): try: assert expr, msg except AssertionError as e: self.errors.append(str(e)) def assert_all(self): if self.errors: raise AssertionError("Soft assertion failures:\n" + "\n".join(self.errors)) def test_ui(page): s = SoftAssert() s.check(page.title == "Home", "title mismatch") s.check(page.find("#banner").is_displayed(), "banner missing") s.check("Welcome" in page.text(), "welcome text missing") s.assert_all() Example — TestNG (Java) java// TestNG example using SoftAssert import org.testng.asserts.SoftAssert; @Test public void uiTest() { SoftAssert soft = new SoftAssert(); soft.assertEquals(driver.getTitle(), "Home", "title mismatch"); soft.assertTrue(isDisplayed("#banner"), "banner missing"); soft.assertTrue(pageContains("Welcome"), "welcome text missing"); soft.assertAll(); // throws at end if any failed } Trade-offs: debugging and flakiness Pros: faster feedback (multiple failures in one run), more context for devs, fewer reruns. Cons: can mask cascading failures—later assertions may fail due to an earlier critical problem; increases noisy failures if used where preconditions fail; stack traces point to assert_all rather than each site (but messages usually include context). Mitigation: combine both—use hard asserts for prerequisites, soft asserts for independent verifications; include clear messages and element snapshots/logs to aid debugging; limit scope of soft assertions to a single page or logical block to reduce flakiness.

EasyTechnical

87 practiced

Explain the Arrange-Act-Assert (AAA) testing pattern. Provide two concrete examples that explicitly label Arrange, Act, and Assert: one unit test (choose Python or Java) and one UI end-to-end test (choose Selenium, Playwright, or Cypress). Explain why AAA improves readability and maintainability.

Sample Answer

What AAA is (brief) Arrange–Act–Assert is a simple structure for tests: set up preconditions (Arrange), execute the behavior under test (Act), and verify outcomes (Assert). It makes intent explicit and keeps tests focused. Unit test example (Python / pytest) pythondef test_add_item_increases_count(): # Arrange: create cart and initial state cart = ShoppingCart() cart.add_item("apple") initial_count = cart.count() # Act: perform the action under test cart.add_item("banana") # Assert: verify expected outcome assert cart.count() == initial_count + 1 assert "banana" in cart.items E2E example (Cypress) javascriptit('Arrange-Act-Assert: login and see dashboard', () => { // Arrange: ensure app is on login page cy.visit('/login') // Act: perform login cy.get('#username').type('qa_user') cy.get('#password').type('s3cret') cy.get('button[type=submit]').click() // Assert: dashboard is visible and shows user name cy.url().should('include', '/dashboard') cy.get('.user-greeting').should('contain', 'qa_user') }) Why AAA improves readability & maintainability Clear separation of concerns makes it obvious what is setup vs action vs expectation. Easier to spot redundant setup or missing asserts; simplifies refactoring test setup into helpers. New team members read intent quickly; failures point to either Act logic or Assert expectations, speeding debugging.

That is every published Assertions and Behavior Verification question for QA Engineer so far. Browse the other topics in this category, or practice this one interactively.

Browse Testing, Quality & Reliability topics Start a practice session