Edge Case Identification and Testing Questions

Focuses on systematically finding, reasoning about, and testing edge and corner cases to ensure the correctness and robustness of algorithms and code. Candidates should demonstrate how they clarify ambiguous requirements, enumerate problematic inputs such as empty or null values, single element and duplicate scenarios, negative and out of range values, off by one and boundary conditions, integer overflow and underflow, and very large inputs and scaling limits. Emphasize test driven thinking by mentally testing examples while coding, writing two to three concrete test cases before or after implementation, and creating unit and integration tests that exercise boundary conditions. Cover advanced test approaches when relevant such as property based testing and fuzz testing, techniques for reproducing and debugging edge case failures, and how optimizations or algorithmic changes preserve correctness. Interviewers look for a structured method to enumerate cases, prioritize based on likelihood and severity, and clearly communicate assumptions and test coverage.

HardSystem Design

89 practiced

How would you integrate fuzz testing into a CI pipeline for containerized microservices so fuzz runs are sandboxed, resource-limited, and produce actionable results rather than noise? Discuss scheduling strategies, sandboxing, crash deduplication, artifact storage for failing inputs, and a process to promote interesting fuzz findings into regression test suites.

Sample Answer

Requirements:- Run fuzzing against containerized microservices in CI safely: sandboxed, CPU/memory/time-limited, non-flaky, and produce triageable findings that can be promoted to regressions.

High-level design:- Orchestrator: CI (e.g., GitHub Actions, GitLab CI, Jenkins) triggers fuzz jobs.- Fuzz runners: dedicated Kubernetes Jobs using fuzzers (AFL++, libFuzzer, OSS-Fuzzish harnesses) inside lightweight sandboxed pods.- Triage service: automated crash dedup, minimization, and classifier.- Artifact store: object storage (S3/GCS) + metadata DB (Postgres/Elastic).

Key components & responsibilities:1. Scheduling- Nightly/weekly heavy fuzz runs on master and release branches; PR-level quick fuzz smoke tests (short corpus, timebox).- Pool of pre-warmed nodes with GPU/CPU quotas for faster startup.- Priority queue: critical services and new code paths get more runtime; use fair-share and rate limits.

2. Sandboxing & resource limits- Kubernetes PodSecurityPolicy / OPA/Gatekeeper for capability drops.- Use cgroups via Kubernetes resource requests/limits and runtime_class (gVisor or Firecracker) for extra isolation.- Limit runtime with jobActiveDeadlineSeconds; network policies to restrict external access; use ephemeral namespaces.

3. Crash deduplication & triage- On crash, run deterministic minimization (libFuzzer -merge or afl-cmin) inside the pod.- Symbolicate and produce unique signature (stack trace + sanitized PC offsets + sanitizer output).- Use fuzzy hashing (e.g., crash signature + ASAN report) to de-duplicate and assign severity via heuristic classifier (sanitizer type, reproducibility, security-sensitive code path).

4. Artifact storage- Store minimized input, core dump, sanitized logs, sanitizer outputs, and container image SHA in object storage with indexed metadata.- Attach links to CI run, reproducer, and stack trace in issue tracker.

5. Promotion to regression tests- Triage service auto-creates reproducible failing test harness and attempts to auto-fix flaky cases. If reproducible and severity >= threshold, create a draft PR with: - A deterministic regression test (added to unit/integration fuzz regression suite). - Reproducer and CI metadata.- Require human reviewer to sign off; merge triggers an automated regression job that runs the failing input generationally to ensure deterministic failure before adding to stable regression suite.

Scalability & observability- Metrics: fuzz job count, time-to-first-crash, uniqueness rate, flakiness rate, queue length.- Alerting: surge of new unique high-severity crashes triggers on-call paging.- Cost controls: autoscale based on queue and prioritize important services.

Trade-offs- Strict sandboxing (gVisor/Firecracker) increases startup latency; mitigate with pre-warmed pools.- Aggressive dedup may hide subtle variants; keep raw artifacts for manual inspection.

This design keeps fuzzing contained, resource-aware, reduces noise via dedup/minimization, stores actionable artifacts, and provides an automated promotion path into regression tests with human oversight.

EasyTechnical

85 practiced

Describe a structured approach to prioritize edge cases for testing when resources are limited. Include a scoring rubric that considers likelihood, blast radius (impact), detectability in production, and cost to remediate. Show an example scoring of three hypothetical edge cases.

EasyTechnical

92 practiced

You have a function `normalize_username(s: str) -> Optional[str]` that trims whitespace, lowercases, removes control characters, and returns None for empty input. Write unit test cases (pytest style) that cover: normal input, leading/trailing whitespace, input that's only whitespace, Unicode combining characters, and very long strings (>256 bytes). Explain assertions for each case.

Sample Answer

Here's a pytest test module covering the requested cases. Each test calls normalize_username and asserts the expected return value and properties.

python

import pytest
from typing import Optional
from yourmodule import normalize_username  # replace with actual import

def test_normal_input():
    assert normalize_username("alice123") == "alice123"

def test_leading_trailing_whitespace():
    # whitespace should be trimmed and lowercased
    assert normalize_username("  Alice.Example  ") == "alice.example"

def test_only_whitespace_returns_none():
    # input that's only whitespace should become empty -> None
    assert normalize_username("   \t\n  ") is None

def test_unicode_combining_characters_normalized():
    # composed vs decomposed forms should be treated consistently.
    s_composed = "e\u0301"        # e + combining acute (decomposed)
    s_precomposed = "\u00e9"      # é (precomposed)
    out1 = normalize_username(s_composed)
    out2 = normalize_username(s_precomposed)
    assert out1 == out2
    # also still a non-empty lowercase string
    assert isinstance(out1, str) and len(out1) > 0

def test_very_long_string_truncated_or_handled():
    # supply >256 bytes (use ascii to make bytes==len)
    long_username = "u" * 300
    out = normalize_username(long_username)
    # expected behavior: either preserved or truncated but not None
    # ensure result is a string, lowercased, and not longer than input
    assert isinstance(out, str)
    assert out == out.lower()
    assert len(out) <= len(long_username)

Explanations of assertions:- test_normal_input: exact match for already-normalized string.- test_leading_trailing_whitespace: ensures trimming and lowercasing; checks dots allowed.- test_only_whitespace_returns_none: whitespace-only inputs must map to None per spec.- test_unicode_combining_characters_normalized: verifies canonical normalization (NFC/NFD) so visually identical characters produce identical outputs and remain non-empty.- test_very_long_string_truncated_or_handled: checks the function handles >256-byte inputs without returning None, preserves lowercase, and does not expand the string; adapt expected length/truncation policy if the implementation specifies a strict max length.

EasyTechnical

77 practiced

You manage a REST GET /items endpoint returning a JSON array. Enumerate 10 specific edge cases you'd include in unit and integration tests (e.g., empty list, huge lists, partially malformed items, null fields, incorrect content-type). For each case indicate whether it should be covered by unit tests, integration tests, or synthetic production tests and explain why.

Sample Answer

1) Empty list response ([]). Integration + Unit. Unit: handler returns [] when DB/query has no rows. Integration: end-to-end verifies clients handle empty payload. Ensures correct status code and no downstream errors.

2) Very large list (pagination/limits). Integration + Synthetic production. Integration tests verify pagination, streaming, and memory usage; synthetic load tests validate performance and OOM/latency at scale.

3) Partially malformed item (one object missing fields). Unit + Integration. Unit tests validate serializer tolerates/filters bad records; integration confirms overall response still valid JSON and consumers can handle sparse items.

4) Null fields within items. Unit + Integration. Unit ensures nulls are serialized as expected; integration verifies contracts (e.g., omit vs null) and consumer compatibility.

5) Incorrect Content-Type returned (e.g., text/plain). Unit + Integration. Unit catches code regression; integration ensures middleware/config returns application/json; alerting rule can detect regressions in prod.

6) Non-JSON body from upstream (DB/cache) causing serialization failure. Unit + Integration. Unit injects bad upstream data to validate error handling; integration confirms graceful 500 with structured error and alerting.

7) Slow backend / partial timeout causing truncated response. Integration + Synthetic production. Integration simulates backend slowness and verifies timeouts and circuit-breakers; synthetic chaos tests validate client-visible latency SLOs.

8) Duplicate items / ordering changes. Unit tests. Verify deduplication and stable sort behavior; integration if ordering is a contract with clients.

9) Authentication/authorization variations (401/403 vs 200). Integration. Validate access controls, rate-limit headers, and that unauthorized requests don’t leak data.

10) Unexpected HTTP method or query params (e.g., GET with huge query string). Unit + Integration. Unit checks request parsing and validation; integration verifies server responds with 400/414 appropriately and logging/metrics capture malformed requests.

For each case choose tests that catch logic bugs early (unit), validate end-to-end behavior and infra interactions (integration), and exercise scale/reliability in a production-like environment (synthetic).

MediumTechnical

92 practiced

A distributed job scheduler enqueues tasks with retries and exponential backoff. Enumerate edge cases that can cause duplicate or lost tasks (clock skew, process crash during ack, duplicate enqueue, queue reordering) and propose tests to detect each issue. Specify instrumentation or assertions you'd add to prove correctness under these scenarios.

Sample Answer

Situation: We're validating a distributed job scheduler with retries + exponential backoff. Below I enumerate edge cases that can cause duplicate or lost tasks, propose targeted tests (unit/integration/chaos), and list instrumentation/assertions to prove correctness.

Edge cases, tests, and instrumentation

1) Clock skew between producers/consumers- Problem: Visibility timeouts, retry scheduling or TTL miscalculated, causing early retries or permanent loss.- Test: Integration test that offsets system clock on one consumer node (simulate NTP skew) and run workload with short visibility timeouts.- Instrumentation/assertions: include wall-clock and monotonic timestamps in task metadata; assertion: retry timestamps are non-decreasing per task when viewed via monotonic clock; alert if observed retry delta < expected min.

2) Process crash during ack (ack lost after processing)- Problem: Task processed but ack not persisted → retried → duplicate processing.- Test: Inject crash right after handler returns but before ack RPC completes (fault injection harness). Run many tasks.- Instrumentation/assertions: each task carries unique idempotency token and handler emits "processed" event with token; assert (processed_events per token) == 1 for strict idempotency OR <= N for allowed duplicates; also assert ack RPC retry detections logged.

3) Duplicate enqueue (producer retry or visibility-timeout reenqueue)- Problem: Same logical task enqueued multiple times.- Test: Simulate producer-side retries by re-submitting identical payloads; also simulate queue re-insert on visibility timeout expiration.- Instrumentation/assertions: Deduplicate by task ID on enqueue or consumer: counter of enqueue attempts per task; assert unique enqueued_ids == unique processed_ids; histogram of enqueue_attempts should match expected retry behavior.

4) Queue reordering (priority changes, multi-partition ordering, or broker non-FIFO)- Problem: Exponential backoff schedule violated, earlier-retry task jumps ahead or is delayed indefinitely.- Test: Use mixed priorities and partition failover to reorder messages; assert ordering of scheduled execution times vs actual execution.- Instrumentation/assertions: store intended schedule timestamp in task metadata; record actual execution timestamp; assert max lateness within SLA percentile (e.g., 99th <= configured jitter + backoff).

5) Network partition / broker failover- Problem: Commit/ack race leads to duplicates or lost tasks if broker leader changes mid-ack.- Test: Simulate broker glitch during ack; run end-to-end scenario with high concurrency.- Instrumentation/assertions: trace spans across enqueue→deliver→ack including broker epoch; assert that any task with ack status "uncertain" is either retried safely or reconciled by a periodic scanner; metric: unresolved_tasks gauge drops to zero after reconciliation.

6) Exponential backoff overflow / max-backoff misconfiguration- Problem: Backoff wraps/overflows or exceeds retention causing task to be dropped.- Test: Configure extreme backoff factors and limits; verify scheduled timestamps remain valid and within retention window.- Instrumentation/assertions: validate compute_backoff(task.attempts) ∈ [min,max]; assert scheduled_time < queue_retention_end.

7) Poison tasks (always failing) causing retry storms or clogging- Test: Create tasks that always fail; verify dead-lettering after max attempts.- Instrumentation/assertions: dead_letter_count metric increments; assert no task exceeds max_attempts without being moved to DLQ.

General instrumentation & correctness proofs- Unique task IDs + idempotency tokens attached at enqueue.- Immutable metadata: enqueue_time, scheduled_time, attempt_count, producer_id, monotonic timestamps.- End-to-end trace/span per task across components (consume, process, ack) with sampling off for tests.- Metrics: processed_count_by_task_id, ack_success/failure, reenqueue_count, dead_letter_count.- Assertions in tests: - Coverage: for N distinct logical tasks enqueued, processed_unique_ids == N (no loss). - Duplicates: processed_events_per_id <= 1 (if guaranteeing once-only) or measured duplication rate within SLO. - Retry timing: measured intervals match expected exponential backoff ± jitter bounds. - Reconciliation: periodic scanner resolves ambiguous states within configured window.

Practical mitigations to accompany tests- Make handlers idempotent and persist side effects transactionally (e.g., write-side-effect + ack in same durable transaction or use two-phase commit patterns).- Use monotonic clocks for scheduling decisions.- Implement at-least-once core with dedup table for exactly-once semantics where required.- Run chaos engineering (clock skew, process kill, network partition) in CI nightlies and assert invariants above.

This combined test+instrumentation strategy detects duplicates or losses and provides measurable assertions to prove system correctness under those distributed failure modes.

Unlock Full Question Bank

Get access to hundreds of Edge Case Identification and Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.