Java JUnit Testing

JUnit is a Java testing framework for writing and running automated tests. It helps verify code behavior continuously, prevents regressions, and supports fast feedback in CI/CD workflows. A method that calculates tax is validated by unit tests on every commit.

JUnit 5 is modular and more extensible. JUnit 5 introduces Jupiter API, better extension model, richer annotations, improved parameterized tests, and cleaner lifecycle handling. `@BeforeEach` in JUnit 5 replaces `@Before` from JUnit 4.

They catch bugs early and protect existing behavior. Tests reduce fear of refactoring, improve design quality, and shorten debugging cycles when changes are frequent. Refactor service logic confidently because behavior is covered by tests.

A test for a small unit of logic in isolation. Unit tests should be fast, deterministic, and independent from external systems like DB/network/files. Testing discount calculation function with mock dependencies.

A test that validates interaction between real components. Integration tests verify boundaries (DB, web, security, messaging) and catch wiring/config issues unit tests miss. Repository + real test DB query behavior.

Unit tests logic in isolation; integration tests component collaboration. You need both: unit for speed and precision, integration for real-system confidence. 1000 unit tests + 50 integration tests is common.

Clear, fast, deterministic, and meaningful. Good tests assert behavior (not implementation details), use readable names, and fail with helpful diagnostics. `calculateTotal<sub>shouldApplyDiscountwhenCustomerIsPremium</sub>`.

They fail randomly and destroy trust. Teams start ignoring red builds when tests are unstable, which weakens quality gates. Test depends on current time/network and passes only sometimes.

Each test should run independently from others. Shared mutable state between tests causes order-dependent failures and brittle suites. Avoid static mutable fixtures reused across tests.

Re-running tests to ensure old features still work after changes. Regression suites are your safety net during refactoring and feature growth. Bug fix gets a test so issue never silently returns.

Marks a method as a test case. JUnit executes methods annotated with `@Test` and reports pass/fail outcomes.

@Test
void shouldReturnSum() { ... }

Provides readable test name in reports. Improves report clarity for non-technical stakeholders and CI dashboards. `@DisplayName("Premium customer gets 10% discount")`

Runs before every test method. Use it for fresh setup required per test to avoid state leakage. create new service instance before each test.

Runs after every test method. Useful for cleanup (temp files, static hooks, context reset). clear ThreadLocal context after each test.

Runs once before all tests in class. Useful for expensive shared setup; must be static unless test instance lifecycle is per class. start embedded server once.

Runs once after all tests in class. Use for releasing expensive shared resources. stop embedded database container.

Temporarily skips a test. Should be used sparingly and documented; disabled tests can hide quality risks. disable flaky external dependency test with TODO reason.

Categorizes tests (e.g., unit, integration). Allows selective execution in CI pipelines. run fast unit tests on PR, full suite nightly.

Groups related tests in inner classes. Improves readability by organizing scenarios/context hierarchically. `WhenUserIsPremium` nested group.

Controls test class lifecycle (per-method/per-class). Per-method is safer default; per-class can optimize expensive setup but needs care for shared state. `@TestInstance(PER<sub>CLASS</sub>)` with non-static `@BeforeAll`.

A check that verifies expected behavior. Assertions are the core of test meaning; weak assertions create false confidence. `assertEquals(expected, actual)`.

assertEquals checks value equality; assertSame checks reference identity. Use assertSame only when object identity is truly required. caching test expecting same instance.

For boolean conditions. Add descriptive messages for failure diagnostics, especially on complex predicates. `assertTrue(total > 0, "Total should be positive")`

Validate presence/absence of value. Useful at API boundaries where null contract matters. repository returns null when no legacy record exists.

Verifies expected exception is thrown. Also allows asserting exception message/type to validate error contract.

var ex = assertThrows(IllegalArgumentException.class, () -> svc.create(null));
assertTrue(ex.getMessage().contains("name"));

Confirms code executes without exception. Use when behavior contract explicitly requires no failure. parsing valid config should not throw.

Groups multiple assertions and reports all failures together. Great for DTO/object field verification in one test. check id, name, email in one assert block.

Both enforce duration; preemptive may interrupt test thread. preemptive timeout can interfere with thread-local/transaction contexts; use carefully. performance guard around heavy algorithm.

Faster diagnosis on failure. Good messages reduce debugging time and improve CI signal quality. include input values in failure message.

Testing too little (or nothing meaningful). A test that only checks non-null while core behavior is wrong gives false confidence. assertNotNull(response) without checking important fields.

Runs same test logic with multiple inputs. Reduces duplication and improves coverage for edge cases systematically. validate multiple invalid email formats.

Simple inline primitive/string input values. Best for quick one-argument parameterized scenarios. `@ValueSource(strings = {"", " ", "abc"})`

Multiple parameters per test row. Good for compact table-driven tests. input amount + expected tax pairs.

Complex/custom argument generation. Ideal when data setup is non-trivial or reusable. stream of domain objects with expected results.

Run tests across enum values. Great for state-machine or role-based branch validation. permissions by user role enum.

More cases with less boilerplate. Encourages boundary-value thinking and reduces copy-paste test code. same validator tested with many corner inputs.

Re-runs same test N times. Useful for probabilistic/flaky behavior checks, though deterministic design is preferred. run concurrency-sensitive test 50 times.

Tests generated at runtime via `@TestFactory`. Useful for data-driven generation when cases are discovered programmatically. generate tests from external rule definitions.

When static tests are clearer. Dynamic tests can reduce readability/discoverability if overused. simple input matrix is clearer with parameterized tests.

Too much logic in data provider. If data construction is opaque, test intent becomes hard to understand. complex method source with hidden branching.

Known test data/environment setup. Stable fixtures make tests deterministic and intention-revealing. user fixture with role=ADMIN for access tests.

Prefer local clarity unless duplication is high. Over-shared setup in @BeforeEach can hide what test truly needs. create only required objects inside test body when simple.

It hides context and slows comprehension. Tests should show relevant setup explicitly for readability. helper builders per scenario instead of one huge global fixture.

Fluent builder for creating test objects. Reduces fixture noise and makes scenario intent explicit. `UserBuilder.aUser().withRole("ADMIN").build()`.

`method<sub>shouldExpectedBehaviorwhenCondition</sub>`. Structured naming improves discoverability and report usefulness. `login<sub>shouldFailwhenPasswordIsWrong</sub>`.

Clear failures and intent. Multi-behavior tests are harder to debug and maintain. separate “valid email” and “invalid email” tests.

Usually no. Test observable behavior through public API; private methods are implementation details. validate final result, not internal helper call.

Mocking too many internals. Leads to brittle tests coupled to implementation, not behavior. verifying every tiny internal method invocation.

Reliable CI and trust. Eliminate random/time/network dependencies unless intentionally controlled. inject Clock instead of using Instant.now directly.

Tests are documentation. Future maintainers should understand scenario quickly without deep code archaeology. clear Given-When-Then structure.

assertThrows + message assertions. Validates not just failure but proper domain error contract. reject invalid ID format with meaningful message.

Too weak and can hide wrong failures. Assert specific expected exception classes for precision. IllegalArgumentException vs RuntimeException catch-all.

Use injected Clock and fixed instant. Avoid wall-clock dependence to prevent flaky tests. `Clock.fixed(…)` for deterministic expiration checks.

Detect performance regressions/hangs. Especially useful around algorithms and async code completion guarantees. ensure task completes under 200ms in test env.

Join/get with timeout and assert value. Always guard with timeout to avoid hanging test suite. `future.orTimeout(1, SECONDS).join()`

Verify invariants under parallel execution. Use latches/barriers/repetition to increase race detection probability. 100 threads increment shared counter then assert final count.

Scheduling is nondeterministic. Race conditions are probabilistic; combine stress tests with code review/static analysis. failing once per thousand runs.

Prefer not. Sleep-based timing tests are flaky and slow; use explicit synchronization. CountDownLatch instead of arbitrary sleep.

Simulate interrupt and assert proper behavior. Verify code preserves interrupt status or propagates cancellation correctly. worker exits cleanly after interrupt.

Fire async task without waiting/asserting completion. Test may pass before async branch runs, producing false positives. always await completion signal/future.

Test double with programmable behavior and interaction verification. Mocks isolate unit under test from external dependencies. mock PaymentGateway in service unit test.

Stub provides canned data; mock also verifies interactions. Use stubs for state assertions, mocks for collaboration behavior checks. stub repository return, verify notifier called once.

External dependencies and slow/non-deterministic collaborators. Don’t mock pure value objects or simple logic classes. mock HTTP client, not Money class.

Couples tests to internals. Prefer result/state assertions unless interaction is the key behavior. don’t verify every helper call.

Create mocks and inject them into class under test. Reduces boilerplate setup and keeps tests focused. service with mocked repository + email sender.

Integrates Mockito lifecycle with JUnit Jupiter. Handles mock initialization cleanly via `@ExtendWith(MockitoExtension.class)`. no manual `MockitoAnnotations.openMocks`.

Partial mock wrapping real object. Useful but risky; can blur unit boundaries and create brittle tests. override one method while using real others.

Only when unavoidable. Frequent static mocking indicates design refactor opportunity for better testability. wrap static utility in injectable adapter.

Stubbing not used / wrong matcher usage. Leads to confusing false behavior; strict stubs help detect dead stubbing. method args mismatch causes unexpected null returns.

Mock behavior boundaries, not your whole architecture. Balanced testing uses real logic where cheap and mocks where expensive/unreliable. mock DB gateway, keep domain logic real.

Wiring/configuration can still fail. Integration tests validate framework config, serialization, DB mappings, security filters. endpoint returns 400 due to validation config issue.

Critical flows and boundaries. Test fewer but high-value scenarios: auth, persistence, transaction, API contracts. create-order endpoint persists and returns expected JSON.

Real DB container is more realistic. In-memory DB may differ in SQL dialect/index behavior. PostgreSQL Testcontainers catches dialect-specific issues.

Reproducible real dependencies in tests. Improves confidence by testing against production-like services. integration test with real Postgres/Redis container.

Status, payload, headers, and side effects. Validate both transport contract and persistence/business result. 201 Created + Location header + row inserted.

Usually fewer. Integration tests are slower/costlier; prioritize high-risk/high-value scenarios. test pyramid balance.

Validate API agreement between services. Prevent producer/consumer drift in distributed systems. provider response schema validated for consumer expectations.

Isolated test data and deterministic setup. Reset DB state, avoid shared mutable environment, control time/randomness. transactional rollback or per-test schema reset.

Unreliable and slow. Causes flaky builds due to network/rate limits/outages. use mock server/wiremock for external APIs.

Scenario-focused behavior naming. Names should describe business flow, not internal method names. `createOrder<sub>shouldPersistAndReturn201whenInputValid</sub>`.

Percentage of code executed by tests. Coverage is a signal, not quality proof; high coverage can still miss critical assertions. 90% coverage with weak assertions is still risky.

Line checks executed lines; branch checks decision paths. Branch coverage better reflects conditional logic validation. both true/false paths of discount rule tested.

Not blindly. Prioritize meaningful coverage on critical logic and risk areas. payment/security logic deserves stronger coverage than trivial DTOs.

Fast unit + key integration smoke tests. Keep feedback fast while catching major regressions early. full heavy suite nightly.

Slow suites reduce developer feedback speed. Faster feedback loops improve productivity and code quality. keep unit suite under few minutes.

Fix quickly or quarantine with clear owner. Ignoring flaky tests erodes trust in entire pipeline. tagged quarantined tests with follow-up issue.

Measures whether tests detect small code changes (mutants). Evaluates test strength beyond coverage metrics. if mutant survives, assertions may be weak.

Ensures quality is part of delivery. Prevents “test later” debt and reduces production defect risk. feature PR requires unit tests + relevant integration test.

They provide behavior safety net. You can improve internal design confidently if tests protect external behavior. service split into smaller classes without behavior change.

Fast unit tests, targeted integration tests, meaningful assertions. Balanced strategy yields speed + confidence + maintainability. test pyramid mindset.

Registers JUnit 5 extensions. Extensions add reusable behaviors like DI, mocks, temp dirs, custom lifecycle hooks. MockitoExtension, SpringExtension.

Provides method parameters to tests dynamically. Enables custom dependency injection into tests. inject test clock/config object automatically.

@EnabledOnOs, @DisabledOnJre, @EnabledIf… Useful when behavior depends on environment constraints. run path-specific tests only on Linux.

JUnit-managed temporary directory injection. Safe filesystem testing without manual cleanup hassles. write/read temp file in isolated path.

Precondition check that aborts (skips) test if unmet. Useful for environment-dependent tests without marking failure. skip test if Docker not available locally.

Repeated cross-test setup/teardown behavior. Encapsulates boilerplate and enforces consistent test conventions. extension to seed and clean DB data.

Scenario grouping by context. Mirrors business rules structure: “given this context, these outcomes”. nested classes for authenticated vs anonymous user.

No, JUnit 5 test methods should not be private. Visibility must allow framework invocation. package-private or public test methods.

Use carefully. Base test classes can reduce duplication but may hide setup complexity. abstract integration base for shared container setup.

Use only if it improves clarity. Fancy features should simplify tests, not impress with complexity. prefer simple parameterized test over custom extension if enough.

Tests break on harmless refactors. Assert externally visible behavior, not private call sequence unless contract requires it. avoid verifying internal helper call counts.

Hard to diagnose failures. Split by behavior/scenario for precise failure signal. separate tests per validation rule.

Non-reproducible failures. If randomness used, seed and log seed. deterministic random with fixed seed.

Flaky and slow. Use latches/futures/timeouts instead of arbitrary wait. await completion signal.

Destroys quality gate. Red build must be actionable and owned immediately. block merge until fixed.

Brittle tests. Over-mocked tests mirror implementation, not behavior outcomes. use real domain objects where cheap.

Errors unverified. Failure behavior is part of API contract. invalid input should return explicit exception/status.

Hidden coupling between tests. Each test should pass independently in any order. reset static/shared state each test.

False confidence. Verify key fields and invariants, not just non-null. assert status, amount, currency, timestamp range.

Edge bugs leak to production. Boundaries (0, 1, max, empty, null) catch many defects. pagination with page=0 and empty results.

Parameterized tests for rule matrix. Table-driven approach keeps tests concise and complete. each row = input + expected error code.

Integration test against real-like DB. Validates unique keys, transactions, and SQL behavior. duplicate email insert should fail predictably.

Slice test (web layer) + mocked service. Focuses HTTP mapping/validation without full app startup. request JSON -> 400 on invalid payload.

Full integration test. Covers controller, service, repository, serialization, and DB together. POST create -> GET fetch -> assert persisted state.

Mock dependency failures then success. Assert retry count, timing strategy hooks, and final outcome. fail twice, succeed third call.

Simulate slow dependency and assert fallback. Validate resilience contract, not just nominal path. fallback response under 200ms deadline.

Verify message emitted with correct payload. For integration, use test broker/consumer assertions. order created emits OrderCreated event once.

Inject fixed Clock. Move through time by controlled clock values. token valid at t0, expired at t0+31m.

Multi-thread increment test + final invariant. Stress with synchronized start and many iterations. expected final count equals threadCount*iterations.

Assert field-by-field mapping. Include null and optional-field cases to prevent silent data loss. entity -> DTO retains timezone and precision.

More unit tests, fewer integration, very few end-to-end. Optimizes speed and reliability while preserving system-level confidence. 1000 unit, 100 integration, 10 e2e (illustrative).

Characterization tests first, then incremental refactor. Lock current behavior before structural changes. golden-master style outputs for critical paths.

Test risk and business impact. Prioritize critical logic, complex branches, and frequently changed code. payment/auth > trivial getters.

Enough to cover critical behaviors confidently. No fixed number; quality and risk coverage matter more than count. all key rules + boundary + error paths covered.

Remove nondeterminism and isolate dependencies. Control time/randomness/network and stabilize async coordination. fixed clock + mock server + no sleep waits.

Over-mocking creates brittle, low-value tests. Balance realism and isolation; mock boundaries, not domain logic. real calculator, mocked external API.

One that explains what failed and why it matters. Include expected vs actual and scenario context. “expected tax=12.50 for premium user, got 10.00”.

Testability pushes modular and loosely coupled code. Smaller components with clear dependencies are easier to test and maintain. inject repository interface instead of static utility.

Keep tests readable and behavior-focused. Tests are long-term documentation and safety net, not just pass/fail checks. Given-When-Then naming and structure.

Fast checks on PR, deeper suite on schedule/release. Balances rapid developer feedback with broad regression confidence. unit+smoke per PR, full integration nightly.

If yes, your testing fundamentals are solid. You can design balanced suites for speed and confidence. choose test type based on risk and scope.

If yes, reliability is strong. Deterministic tests are key to trusted CI pipelines. latch/future + timeout patterns.

If yes, robustness improves. Failure behavior is product behavior too. invalid input returns expected error code/message.

If yes, coverage and maintainability improve together. Table-driven tests reduce duplication and missed edge cases. many invalid emails in one concise test.

If yes, test value is higher. Behavior-oriented tests survive refactors better. state assertions over interaction obsession.

If yes, production confidence rises. Focus on critical boundaries and real dependencies. DB transaction + API serialization checks.

If yes, team velocity stays healthy. Naming, structure, fixtures, and helpers prevent test entropy. scenario-based nested test organization.

If yes, your strategy is mature. Strong assertions + branch/risk coverage matter more than vanity metrics. critical branch tests over trivial getter coverage.

If yes, CI stability improves. Identify nondeterminism source, isolate, and harden. clock/random/network control checklist.

Write tests that future you can trust and understand. Good tests are executable documentation, regression safety net, and design feedback tool. clear, deterministic, behavior-focused suite.