Recruitment and knowledge question base. Filter, search and test your knowledge.
Unit tests verify small pieces in isolation, integration tests verify collaboration between components, and end-to-end tests validate full user flows across the system.
The test pyramid says you should have many unit tests, fewer integration tests, and a small number of E2E tests. It matters because it balances speed, cost, and confidence.
Stubs provide fixed responses, mocks verify interactions, and fakes are lightweight implementations (e.g., in-memory DB). They serve different goals in tests.
Flaky tests fail nondeterministically due to timing, shared state, or environment issues. Fix them by isolating state, controlling time, waiting for conditions not sleeps, and stabilizing environments.
Contract testing verifies that services agree on request/response schemas and behaviors without full end-to-end tests. It’s useful in microservices and external integrations.
Property-based testing checks general properties over many generated inputs rather than fixed examples. It’s useful for edge cases and complex logic.
Coverage shows which lines/branches were executed, but not whether tests assert correct behavior. High coverage doesn’t guarantee quality; low coverage doesn’t mean tests are useless.
TDD (Test-Driven Development) is writing a failing test first, then making it pass and refactoring. It helps clarify requirements and design when logic is complex or risky.
Use deterministic clocks, await completion, and assert on outcomes. For concurrency, test invariants, use controlled schedulers, and avoid timing-based sleeps.
Use small, readable fixtures or factories, reset state between tests, and keep data close to the test intent. For integration tests, seed minimal data and clean up reliably.