What is Unit Testing?

Unit testing is the practice of testing a single function, method, or class in isolation from the rest of the system. A unit test calls the target with specific inputs, asserts on the output and side effects, and uses mocks or stubs for any dependencies the target calls. The goal is to catch logic bugs in the code you wrote — wrong conditionals, off-by-one errors, incorrect return values — without running the full application.

Five properties. It runs fast (milliseconds, not seconds). It is deterministic — the same inputs always produce the same pass or fail. It tests one behavior per test, so a failure points to a specific thing. It mocks every external dependency so it does not depend on network, database, or filesystem state. And it has a clear, descriptive name that explains what broke when it fails. Tests that fail these criteria get disabled or deleted and stop providing value.

Unit tests isolate a single function and mock every dependency. Integration tests exercise a group of components together with real dependencies. Unit tests catch logic bugs fast; integration tests catch contract and boundary bugs where most production failures actually live. Both are necessary — a codebase with only unit tests passes the unit suite and breaks in production; a codebase with only integration tests is slow to get feedback on local code changes. See /what-is-integration-testing for the full comparison.

Every language has a dominant choice. JavaScript / TypeScript: Jest or Vitest. Go: the built-in testing package plus testify for assertions. Java: JUnit 5. Python: pytest. Rust: the built-in test harness plus proptest for property-based testing. C# / .NET: xUnit. Ruby: RSpec. The specific framework matters less than picking one, using it consistently, and wiring it into CI.

Yes — via the Keploy Test Agent, which uses LLMs to generate unit tests from source code and pull request diffs. The Test Agent runs on every PR, identifies changed functions, and proposes unit tests that cover the new behavior. This is separate from Keploy's core product (API / integration testing from real traffic capture) because unit testing does not benefit from traffic capture — unit tests operate below the HTTP layer where there is no traffic to capture.

Coverage percentage is a weak proxy for test quality. A codebase with 90% line coverage and no assertions is worse than a codebase with 40% coverage and focused tests on the complex logic. A better framework is to aim for 100% branch coverage on pure functions and business logic, skip the trivial getters and DTO classes, and supplement with integration tests for anything involving external state. The exact number depends on how critical the code is — payment processing should approach 100%, a CRUD controller can be much lower.