unit-testing

Annotate the test class with @ExtendWith(MockitoExtension.class), declare dependencies as @Mock fields, and inject them into the class under test with @InjectMocks. Structure each test as Given/When/Then, stub with when(...).thenReturn(...), assert with AssertJ, and verify required interactions with verify(mock).method(...).

Name each test should<Behavior>_when<Condition>() so it describes exactly one behavior, and group tests into @Nested classes such as SuccessCases, FailureCases, EdgeCases, and Validation. A failing suite then immediately signals which category of behavior broke.

No. Mock only external dependencies of the class under test, never the class itself. Spying on or mocking the service being tested defeats the purpose of the test and hides real behavior; use @InjectMocks so real logic runs against mocked collaborators.

Exclude only genuinely behavior-free classes such as DTO records, JPA entities with only getters and setters, trivial enums, and @Configuration classes with only @Bean declarations, typically at the package level. Never exclude services, controllers, or repositories with real logic just to hit a coverage target.

Skip unit tests for classes with zero conditionals, branches, or custom logic, such as plain DTO records or trivial configuration classes, since they add noise without signal. If such a class later gains validation or behavior, it earns a test at that point.

No. Unit tests must stay fast and isolated, so any real database or network call belongs in integration tests using Testcontainers or @SpringBootTest instead. A unit test that hits external systems becomes flaky and slow and stops being a unit test.