Error Handling
// Definition
The code logic that intercepts and responds to failures — network timeouts, unexpected input, downstream service errors, and exceptions — preventing crashes and providing meaningful feedback. Error-handling paths are among the most under-tested surfaces: they are rarely exercised in the happy path but are critical for resilience and user experience under real-world conditions. Testing strategies: force the failure condition (inject a 500, disconnect the network, supply invalid input); verify the application surfaces a user-friendly message rather than a raw stack trace; confirm the app recovers correctly when the error clears; check error logs contain enough context to diagnose without exposing sensitive data (PII, tokens, internal paths).
// Related terms
Negative Testing
Testing what a system does with invalid, unexpected, or out-of-bounds input — verifying it fails gracefully rather than behaving incorrectly. Complements positive (happy-path) testing. Examples: submitting a form with an empty required field, sending a string where an integer is expected, exceeding maximum field length, passing an expired token. A system passes negative testing when it returns a clear, appropriate error and does not crash, corrupt data, or leak internal state.
Resilience Testing
Testing that a system degrades gracefully and recovers correctly under adverse conditions: slow networks, service timeouts, partial failures, high load, and dependency outages. Covers retry and timeout verification, circuit-breaker triggering, failover, and recovery-after-crash scenarios. Broader than chaos engineering (which targets production-level fault injection) — resilience testing is conducted in controlled test environments.
Retry Logic
Re-running a failing test or step automatically. Useful for taming flake from infrastructure issues — but can mask real bugs if used as a band-aid for genuinely flaky tests.
Error Guessing
Designing tests based on the tester's intuition about where defects are likely to occur. Powered by experience and knowledge of common failure modes — null inputs, off-by-one errors, race conditions.