Mastering Java Unit Tests: Why Write Them and How to Do It Right

About Testing

1. What testing includes

Broadly, testing covers UT, IT, stress testing, hardware testing, etc. This article focuses on Unit Testing (UT).

2. What is UT

Unit testing (also called module testing) verifies the correctness of the smallest testable parts of a program. In procedural code a unit is a function or procedure; in OOP it is a method, including those in base, abstract, or derived classes.

In short, it exercises code with test cases that do not depend on external services such as HTTP APIs or databases, allowing the tests to pass on any machine at any time.

3. Why write UT

Improves code reliability, makes you more aware of code structure, forces higher‑quality code, and more.

4. Why not write UT

Common reasons include code complexity, lack of abstraction, perceived high effort, and maintenance difficulty.

Code‑related reasons: high complexity and missing abstractions make UT intimidating. Workload reasons: writing UT often requires about three times the amount of code compared to business logic to achieve sufficient coverage. Maintainability reasons: test code can be less readable and harder to maintain.

5. What blocks you from writing UT

Additional code volume, lack of readability, and poor habits make test code hard to read and maintain.

6. What a qualified UT looks like

Tests the internal logic of a single code unit, not inter‑module interactions. Has no external dependencies and does not require a runtime environment. Executes quickly and can be run at any time.

Java How to Write UT

Java developers typically use JUnit or TestNG; JUnit 4 is the most common.

7. Naming

Refer to “7 Popular Unit Test Naming” for guidelines.

8. Assertion

Each UT should contain at least one assert. Use assertions such as assertEquals(200, statusCode) instead of printing results with System.out.println(). Assertions verify the outcome of executed branches but cannot guarantee that all branches were exercised.

9. Why mock

Mocking allows tests to run without real dependencies, though it requires careful design.

10. Mock frameworks

Common libraries include Mockito, JMockIt, EasyMock, PowerMock, etc. Choose the one that fits your needs.

Example preference: Mockito, because it is actively maintained, offers a fluent API similar to Java 8 streams, and provides intuitive constructs such as when().thenReturn(), doThrow().when(), verify(), etc.

11. When to mock

External services like databases, RPC calls, third‑party SDKs. Environment variables, system properties, and static methods. Any functionality not belonging to the class under test. Mocking is essentially providing a proxy implementation for required behavior.

12. When not to mock

Methods of the same class that are covered by the class’s own UT. Static methods that can be tested directly. Protected methods (testable when test class is in the same package). Private methods: test via the public methods that invoke them, or refactor to expose functionality.

13. Designing test‑friendly interfaces

Dependency Injection. Abstraction: extract interfaces and keep code concise. Open/Closed Principle: extend without modifying existing code. Avoid unnecessary static methods; if needed, inject references instead of hard‑coding. Test the class behavior, not its internal implementation.

Test Coverage

Coverage is a matter of opinion. Focus on core logic, boundary conditions, and complex decision paths. Low‑level DAOs or simple service wrappers may be exempt.

IDEA Plugin

Recommended plugin: JUnitGeneratorV2.0 (invoke with Command+N or Alt+Enter on a class).

Conclusion

There is no code that cannot be tested; the difficulty lies in code design. Regardless of the testing framework, poorly designed code remains hard to test. When faced with “my code has too many dependencies to write UT,” focus on refactoring for testability rather than searching for a magical tool.