Testability and Testing Practices Questions

Emphasizes designing code for testability and applying disciplined testing practices to ensure correctness and reduce regressions. Topics include writing modular code with clear seams for injection and mocking, unit tests and integration tests, test driven development, use of test doubles and mocking frameworks, distinguishing meaningful test coverage from superficial metrics, test independence and isolation, organizing and naming tests, test data management, reducing flakiness and enabling reliable parallel execution, scaling test frameworks and reporting, and integrating tests into continuous integration pipelines. Interviewers will probe how candidates make code testable, design meaningful test cases for edge conditions, and automate testing in the delivery flow.

EasyTechnical

114 practiced

Compare fakes, stubs, and mocks for replacing a database in tests. As an SRE, when would you prefer a lightweight in-memory fake database versus spinning up an isolated real database instance for integration tests, and why?

HardTechnical

66 practiced

Case study: a production outage occurred because tests used a mock that omitted a newly required authentication header, and the change reached production undetected. Run a post-incident review focused on test gaps, pipeline shortcomings, contract testing adoption, owner responsibilities, and produce a prioritized action list to prevent recurrence.

Sample Answer

Situation: A production outage occurred when a deployment introduced a change requiring an authentication header. Tests passed because a mocked downstream service omitted the new header validation; therefore the integration broke in production.

Root cause analysis:- Primary: Incomplete mock/stub used in tests did not validate the new auth header, so integration tests gave false positives.- Secondary pipeline gaps: CI ran unit and mocked integration tests but lacked end-to-end (E2E) or contract verification against the real service contract. No gating that validated API contract changes.- Ownership: No explicit owner for downstream contract changes; teams relied on implicit coordination.- Observability: Alerts surfaced errors but too late — no pre-deploy contract mismatch detector.

Impact: 45 minutes downtime, failed requests increased by 300%, customer-facing errors and incident response costs.

Action plan (prioritized, owner, ETA, success metric):1) Immediate (24–72h) — Rollback + hotfix; add temporary runtime fallback to accept missing header where safe. Owner: Oncall SRE. Metric: Recovery <1h for similar regressions. 2) High (1–2 weeks) — Adopt contract testing (Pact or similar) for all inter-service APIs; enforce CI gating: consumer-driven contract verification and provider verification in pipeline. Owner: Dev team + SRE. Metric: 100% of services with contract tests; zero contract mismatches in CI. 3) High (1–2 weeks) — Replace brittle mocks in integration tests with lightweight provider emulators that enforce header/validation rules or run tests against a staging instance of the real service. Owner: Dev teams. Metric: Integration test failures for contract violations >0 in CI.4) Medium (2–4 weeks) — Add a CI job that runs schema/contract diffs and flags breaking changes; require explicit approval for breaking contract changes. Owner: Platform/CI team. Metric: All PRs with contract diffs require sign-off.5) Medium (2–4 weeks) — Define and assign contract owners; include change process in API lifecycle docs. Owner: Engineering leadership. Metric: 100% contracts with an owner listed in repo/registry.6) Medium (2–6 weeks) — Enhance observability: add synthetic canaries and pre-production smoke tests that validate auth flows. Owner: SRE. Metric: Canary failures detected pre-prod >0 and alerts created.7) Low (4–8 weeks) — Run chaos tests that simulate header omission to validate system resilience. Owner: SRE/QA. Metric: Successful test runs and documented mitigations.8) Ongoing — Train teams on contract-first development and add contract checks into PR templates. Owner: Eng Enablement. Metric: Training completion rate; reduced post-deploy contract incidents.

Prevention controls and trade-offs:- Contract testing prevents class of regressions but increases CI time; mitigate via parallelization and selective gating.- Provider emulators increase fidelity but require maintenance—start with high-risk APIs first.

Follow-up: 30-day review to validate metrics, enforce owners, and add the contract tests into the SLO definition for inter-service API reliability.

MediumTechnical

92 practiced

Design a reproducible approach to seed complex relational test data for integration tests that includes schema migrations, idempotent seeds, fast setup and teardown for CI, and support for parallel test execution without collisions.

Sample Answer

Approach (high-level goals): reproducible migrations, idempotent seeds, fast setup/teardown, and parallel-safe isolation.

1) Migration & schema management- Use a migration tool (Flyway/Liquibase). Keep migrations immutable and versioned in repo.- Apply migrations in CI before seeding; fail fast on drift.

2) Idempotent seeds- Implement seeds as idempotent SQL or script tasks: use UPSERT/INSERT ... ON CONFLICT or check-exists then insert.- Store seed versions/checksums in a seeds table to avoid reapplying or to detect changes.

Example idempotent SQL:

sql

-- languages: sql
INSERT INTO roles (id, name)
VALUES ('00000000-0000-0000-0000-000000000001','admin')
ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name;

3) Deterministic test data- Use fixed IDs/UUIDs or seeded RNG to make data deterministic across runs.- Keep sensitive/huge records minimal; return only required fixtures.

4) Parallel test isolation- Create either: - ephemeral DB per CI job (recommended) via Docker/Testcontainers or managed DB instances named by job id; or - per-worker schema namespaces (create schema test_worker_42) and set search_path per connection.- Ensure migrations + seeds run against that isolated DB/schema.

5) Fast setup/teardown for CI- Use DB snapshots: after applying migrations+seeds once, take a filesystem-level snapshot (or logical dump). For each job restore snapshot (fast).- Alternatively, keep a warmed container image with initialized DB.- Teardown: drop DB or schema; ensure cleanup in CI even on failure (trap/ finally).

6) Transactional tests & cleanup- For unit/integration tests that can run in single connection, wrap in DB transactions and rollback per test for speed.- For tests requiring multiple connections, use isolated DB/schema approach.

7) Automation & observability- Provide CLI: db/migrate, db/seed --env=test --schema=...- Fail CI if seed checksum mismatches migration state.- Log duration; add metrics for setup time.

Trade-offs:- Per-job DB costs more infra but safest and fastest at scale. Schema-per-worker saves infra but needs careful naming and privileges.- Snapshots trade disk space for speed.

This design ensures deterministic, idempotent seeds, reproducible migrations, fast provisioning via snapshots/containers, and safe parallel execution by isolating schemas or databases.

EasyTechnical

80 practiced

Describe best practices for organizing and naming tests in a repository maintained by SREs. Include how to structure unit, integration, and smoke tests in a monorepo, and show how naming conventions can help CI select tests, expedite triage, and surface slow or flaky tests.

HardTechnical

76 practiced

As a staff SRE, propose a shift-left roadmap to improve reliability by moving tests earlier in the development lifecycle. Include libraries or test harnesses to provide, CI policy changes to enforce, developer education and onboarding, metrics to track adoption, and a plan to handle cultural resistance and risk.

Sample Answer

Situation/Goal: As staff SRE I want to reduce production incidents by moving tests left so defects are found earlier, reduce time-to-fix, and protect error budgets.

Roadmap (6 months, phased):1. Foundations (month 0–1)- Provide reference libraries/harnesses: unit test templates (pytest/junit), contract testing with Pact, integration harness using Testcontainers (Java/Python), a lightweight e2e framework (Playwright/Selenium), API mock server (WireMock), local dev environment via devcontainers.- Publish a “reliability starter kit” repo with templates, GitHub Actions/Concourse pipeline examples, and Dockerized test runners.

2. CI & policy (month 1–3)- Enforce CI gates: PRs must pass linters + unit tests; require smoke integration in PR for services touching infra; block merge if contract tests fail.- Introduce staged pipelines: quick checks on PR, heavier integration and contract tests on merge-to-main, nightly full e2e/load runs (k6).- Add soft policy flags initially (warnings) then hard blocks after pilot.

3. Developer enablement (month 1–4)- Run hands-on workshops, recorded walkthroughs, pairing sessions, office hours.- Onboarding checklist: write 3 unit tests + 1 contract test before first PR; reviewer checklist includes “tests added”.- Create playbooks for writing reliable tests and reducing flakiness.

4. Measurement & feedback (ongoing)- Track adoption metrics: % PRs with tests, % services with contract tests, CI pass rate, test flakiness rate, mean time to detect (MTTD), production incident rate & error budget burn.- Dashboards and weekly reports; tie improvements to SLO improvements.

5. Risk & rollout strategy (months 3–6)- Pilot with 2-3 teams, measure ROI, iterate tooling.- Use feature flags, canary deployments, and traffic shaping to reduce risk from new pipeline behavior.- Gradually expand policy enforcement.

Handling cultural resistance & risk- Start with pilots and measurable wins; publicize results (reduced incidents, faster rollbacks).- Make it easy: templates, one-click pipelines, and pairing support reduce friction.- Incentivize: celebrate teams, include reliability work in performance goals.- Address fear of slower CI by optimizing test pyramid: fast unit tests first, selective integration on PRs, parallelism in CI.- For legacy brittle tests, offer “test debt sprints” and temporary exemptions with remediation timelines.

Why this works- Tools + templates reduce cognitive load; CI policy creates guardrails; education builds capability; metrics prove value; phased rollout and canaries manage risk and social buy-in. Together this shifts detection left, lowers incident frequency, and preserves velocity.

Unlock Full Question Bank

Get access to hundreds of Testability and Testing Practices interview questions and detailed answers.

Join thousands of developers preparing for their dream job.