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

119 practiced

Define smoke tests and regression tests. For a small web service propose a minimal smoke-test suite to run after deployment, explain why you would run smoke tests immediately and full regression less frequently, and describe trade-offs in the pipeline.

MediumTechnical

88 practiced

Describe how to use a mocking framework such as Mockito to replace external dependencies in unit tests. Show examples of stubbing return values, verifying interaction counts, and using argument matchers. Then discuss the risks of over-mocking and tests that assert implementation details rather than behavior.

Sample Answer

To isolate unit tests from external dependencies, use Mockito to create lightweight test doubles (mocks) that replace collaborators so you test behavior of the unit under test rather than real I/O or slow services.

Approach and examples:1) Stubbing return values

java

import static org.mockito.Mockito.*;

@Test
void stubExample() {
  ExternalService svc = mock(ExternalService.class);
  when(svc.fetchUser("alice")).thenReturn(new User("alice", 42));

  MyController ctrl = new MyController(svc);
  User u = ctrl.getUser("alice");
  assertEquals(42, u.getAge());
}

2) Verifying interactions (counts)

java

@Test
void verifyExample() {
  Repository repo = mock(Repository.class);
  Service svc = new Service(repo);

  svc.process();
  verify(repo, times(1)).save(any());
  verify(repo, never()).delete(any());
}

3) Argument matchers

java

when(repo.findById(argThat(id -> id > 0))).thenReturn(Optional.of(entity));
verify(repo).save(argThat(e -> e.getStatus().equals("READY")));

Key reasoning:- Stubs control dependency behavior to exercise code paths.- Verifications ensure the unit invoked collaborators correctly.- Argument matchers enable flexible checks without coupling to exact object instances.

Risks and best practices:- Over-mocking creates brittle tests that mirror implementation choices; they break on refactors even if behavior is unchanged. Prefer verifying observable outcomes and state over internal call sequences unless the interaction is part of the contract.- Mocking too many layers hides integration issues. Use integration tests with real components (in-memory DB, test HTTP) to catch contract regressions.- Avoid using Mockito.spy() and excessive doReturn/doThrow on real objects unless necessary.- Keep tests fast, deterministic, and focused on behavior: given inputs, expect outputs or side effects. Use mocks for external boundaries only.

MediumTechnical

89 practiced

Compare approaches to test data management: static fixtures, factories, builders, and test-only repositories. Given a domain with orders, invoices, and customers, recommend a strategy for maintainable test data and explain how to handle schema versioning and migrations for tests.

Sample Answer

Recommendation summary: use a mix — small immutable static fixtures for simple, canonical cases; factories for most tests; builders when domain objects require complex valid states; and test-only repositories for controlled integration/DB scenarios.

Why:- Static fixtures: fast, readable, good for smoke tests and examples. But brittle when schema/business rules change.- Factories: generate minimal valid objects on demand, avoid duplication, allow overriding attributes per test.- Builders: encapsulate complex construction logic (e.g., order with multiple line items, tax rules, invoice state transitions).- Test-only repositories: provide deterministic DB state for integration tests (seeded datasets, test-specific queries), isolate DB concerns.

Concrete pattern (Python-like factory + builder):

python

# factory: minimal valid objects
def customer_factory(**overrides):
    data = {"name":"Acme","email":"a@acme.com"}
    data.update(overrides); return Customer(**data)

# builder: fluent API for complex setups
class OrderBuilder:
    def __init__(self): self.customer = customer_factory(); self.lines=[]
    def with_line(self, sku, qty, price): self.lines.append(Line(sku,qty,price)); return self
    def apply_discount(self, pct): self.discount = pct; return self
    def build(self): return Order(customer=self.customer, lines=self.lines, discount=getattr(self,'discount',0))

Schema versioning & migrations for tests:- Always run the same migration pipeline in CI that production uses. Tests should apply migrations to a fresh test DB (no direct schema hacking).- Keep migration scripts idempotent and versioned (Flyway/Liquibase/rails/ alembic).- For fast unit tests mock DB interactions or use in-memory DB with the same migration steps.- Maintain migration-aware factories/builders: use factories that derive defaults from current schema (centralized defaults), and add compatibility layers (feature flags or versioned factories) when schema changes.- For breaking migrations, provide transitional factories and test-only migration helpers that can seed both old and new column data; include migration integration tests that verify data transformations.- CI: matrix tests that run before/after migrations (pre-migration/export -> migrate -> import -> assert) for critical schema changes.

Operational best practices:- Keep factories deterministic and small; avoid overuse of deep object graphs unless needed.- Isolate slow test-only DB suites and run them in separate CI jobs.- Use snapshots for regression of serialized API/DB outputs.This strategy balances maintainability, speed, and robustness as the domain (orders/invoices/customers) evolves.

EasyTechnical

83 practiced

What conventions do you use to organize and name test files and test cases in a large codebase to aid discoverability and running subsets of tests? Describe folder layout, naming schemes for tests and test classes, and how to structure projects to support fast targeted runs.

HardSystem Design

91 practiced

You own a payment microservice. Design a testing strategy that gives deployment confidence: unit tests, consumer-driven contracts, provider verification, integration tests with stubs, canary deployments, feature flags, and chaos experiments. Explain automation, gating conditions, and rollback criteria.

Sample Answer

Requirements & constraints:- Payment microservice must be correct (no wrong charges), highly available, low-latency, and safe to deploy without causing financial loss. Support frequent releases with strong observability and fast rollback.

High-level testing & deployment strategy (layers):1. Unit tests- Fast, deterministic, cover business logic (validation, rounding, currency conversion, retry backoff).- Run on every commit in CI (JUnit/PyTest). Coverage targets and mutation testing for critical code paths.

2. Consumer-Driven Contracts (CDC)- Consumers (checkout, refund, billing) publish contract expectations (e.g., Pact).- Contracts stored in a broker and validated by CI of producers.

3. Provider verification- On producer (payment service) CI, run pact-provider verification to ensure service meets consumer contracts before merge.

4. Integration tests with stubs- CI/CD runs integration tests using lightweight stubs/mocks for external payment gateways and ledger services (wiremock, test-containers).- Separate pre-prod environment runs integration tests against sandboxed real dependencies where available.

5. End-to-end (E2E) & acceptance- Scheduled E2E tests in staging that run realistic flows (authorization -> capture -> settlement) using test cards in a sandbox gateway, validating downstream ledger and notification events.

6. Canary deployments + feature flags- Deploy to a small percentage of traffic (e.g., 1-5%) behind a feature flag. Gradually ramp traffic while monitoring health and business metrics.- Feature flags allow immediate disable without redeploy.

7. Chaos & resilience testing- Run controlled chaos experiments in staging/canary (terminate instances, inject latency/faults, simulate gateway throttling) using Chaos Toolkit or Litmus to validate retries, idempotency, and circuit breakers.

Automation & CI/CD:- Pipeline stages: unit -> static analysis -> contract publish -> provider verification -> integration (stubs) -> build artifact -> deploy to canary -> canary validation -> promote to prod.- Use pipeline as code (GitHub Actions/Jenkins/ArgoCD) with automatic gating and artifact immutability.- Automate contract publishing on consumer CI and automatic provider verification via webhook to producer pipeline.

Gating conditions (to promote or roll back):- Functional: all unit + provider-verification + integration tests pass.- Contract: no breaking contract changes; consumers must approve if contract evolves.- SLOs & health: error rate < threshold (e.g., <0.1%), 95th latency < target, no new payment reconciliation mismatches.- Business checks: daily settlement totals within expected variance, no spike in failed payments, key KPIs within 3σ of baseline.- Security: dependency scans and secrets checks passed.

Rollback & mitigation criteria:- Automatic rollback triggers if during canary or early production: - Error rate exceeds threshold or increases by >X% over baseline. - Latency degradation above SLO for sustained window (e.g., 5 min). - Reconciliation mismatches or duplicate charges detected. - Critical alarms (fraud, PCI warnings).- Rollback action: - Immediately disable feature flag or route traffic away from canary via load balancer/traffic management (Istio/Linkerd). - If health not restored, automated pipeline performs rollback to previous artifact and notifies on-call. - Run post-rollback diagnostic job to capture traces, logs, and diffs for RCA.

Observability & verification:- Instrument traceable transaction IDs across services, structured logs, metrics (Prometheus), and alerts (PagerDuty).- Automated canary analysis (e.g., Kayenta/Flotilla) compare baseline vs candidate across metrics and business KPIs.- Daily reconciliation jobs validate ledger consistency; failures stop promotion and trigger rollback.

Trade-offs & rationale:- CDC prevents consumer regressions but needs coordination for contract evolution—use semantic versioning and consumer-driven contracts with provider-side testing.- Extensive E2E against real gateways gives confidence but is slow; keep them scheduled and use sandbox for pre-prod smoke.- Chaos tests improve resilience but only run in non-prod or tightly controlled canaries.

What I’d implement first:- CI enforcement of unit + contract verification, automated canary deploys with short-lived feature flags, and robust observability (traces, metrics). Then add chaos experiments and E2E sandboxes once rollback automation is mature.

This layered approach provides deterministic safety (tests & contracts), runtime safety (canaries & flags), and resilience validation (chaos), enabling confident, frequent deployments for a payment service.

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.