Contrast UI vs backend testing; design UI-change test cases
Overview
This question evaluates proficiency in test strategy and test-case design for web applications, covering distinctions between UI and backend testing responsibilities, mocking and contract boundaries, flakiness mitigation, security test placement, accessibility, analytics instrumentation, and expanded coverage metrics.
Part A — Differentiate UI vs backend testing: For a single-page web app backed by a BFF (backend-for-frontend) that calls a payment API, explain precisely: (1) What belongs in UI tests (e.g., visual state, accessibility, client-side validation, routing) vs backend tests (e.g., business rules, data integrity, idempotency)? (2) Which layers you would mock/stub in unit, component, contract, integration, and E2E tests; justify the mock fidelity and what you refuse to mock. (3) How you prevent flaky tests (network, time, async) and detect regressions (test oracles, golden images, contract tests). (4) What security checks go where (XSS, CSRF, authZ), and how you enforce idempotency on retries. (5) How you measure coverage beyond code coverage (requirements, risk, and data coverage).
Part B — Design test cases for a specific UI change: The checkout page adds a new Promo Code text field with an Apply button. When applied, the UI asynchronously validates the code with the BFF, updates the total, persists the promo on the order, and emits an analytics event. Provide a concise but thorough test matrix including:
- Functional + negative: empty, whitespace, invalid format, expired, single-use already used, incompatible with items, max applications per order, case sensitivity, leading/trailing spaces, duplicate apply clicks, remove code.
- Boundary: min/max length, Unicode/RTL input, emoji, extremely long paste, SQL/JS injection attempts shown safely, 0% and 100% discounts, rounding rules for fractional cents.
- Accessibility: label/aria attributes, focus order, keyboard-only flow, screen-reader announcements on success/error, contrast of error states.
- Cross-compatibility: major browsers, mobile/desktop viewports, zoom levels, reduced motion, high-contrast mode, slow CPU, low bandwidth.
- Resilience: offline/timeout/server 429/5xx, retry/backoff, idempotent apply, stale promo invalidation if cart changes, eventual consistency (UI reflects server truth).
- Backend/contract: exact request/response schema, versioning, error codes, currency and locale effects, time-zone cutoffs for expiry, audit logging.
- Analytics/experimentation: event name/payload, once-per-apply semantics, A/B flag behavior, PII handling. For each, specify the test type (unit/component/contract/integration/E2E), what to mock, and the acceptance oracle (what must be asserted).