Comprehensive Guide to Unit Testing Strategies and Tools for Java Projects

In the past two years unit testing has become a hot topic; companies now emphasize test pass rates and coverage, turning testing from an afterthought into a disciplined practice that boosts team efficiency and software quality.

Legacy projects with massive codebases often suffer from "test debt"—deeply nested calls and massive classes that make writing tests feel hopeless. The article stresses teamwork to tackle this debt, acknowledging the effort but highlighting the payoff of higher code quality.

The proposed solution follows a four‑step strategy: (1) use mocks to isolate external dependencies, (2) apply a divide‑and‑conquer approach to prioritize core versus non‑core code, (3) generate tests automatically with AI‑powered or commercial tools, and (4) refactor code where testing reveals design flaws.

For concrete implementation the author chooses JUnit 4 combined with Mockito (including mockito‑inline for static methods) over PowerMockito, noting that PowerMockito interferes with coverage tools like JaCoCo.

POM dependencies required for the test stack are shown below:

<dependencies>
<!-- mockito‑core -->
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>3.12.4</version>
<scope>test</scope>
</dependency>
<!-- mockito‑inline for static methods -->
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-inline</artifactId>
<version>3.12.4</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>

The accompanying Jacoco and Surefire plugin configuration ensures coverage data is correctly captured:

<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.3</version>
<executions>
<execution>
<id>pre-unit-test</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<propertyName>jacocoArgLine</propertyName>
</configuration>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
...

Step 1 – Reduce the test base : Exclude generated code (e.g., Lombok @Data, MapStruct) from coverage by configuring lombok.config and upgrading MapStruct to a version that adds @Generated annotations.

Step 2 – Reflection‑based coverage : Automatically invoke constructors and methods of POJOs, enums, and wrapper classes using reflection. The core implementation is shown below:

package com.xx.xx;
import com.google.common.collect.Lists;
import com.google.common.reflect.ClassPath;
import lombok.extern.slf4j.Slf4j;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.junit.MockitoJUnitRunner;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.math.BigDecimal;
import java.util.*;
@Slf4j
@RunWith(MockitoJUnitRunner.class)
public class PojoCoverTest {
private static final List
POJO_PACKAGE_LIST = Lists.newArrayList(
"com.xx.xx.xx.cache.promotion",
"com.xx.xx.xx.domain",
// ... other packages ...
);
private ClassLoader classLoader = null;
@Before
public void before() {
classLoader = Thread.currentThread().getContextClassLoader();
}
@Test
public void domainCoverTest() {
for (String packageName : POJO_PACKAGE_LIST) {
try {
ClassPath classPath = ClassPath.from(classLoader);
Set
classInfos = classPath.getTopLevelClassesRecursive(packageName);
for (ClassPath.ClassInfo classInfo : classInfos) {
coverDomain(classInfo.load());
}
} catch (Throwable e) {
log.error("domainCoverTest Exception package:{}", packageName, e);
}
}
}
// ... helper methods canInstance, method, getValue ...
}

Step 3 – Automated test generation : Tools such as Diffblue (AI‑based, paid), SquareTest (commercial) and TestMe (free) can generate unit tests in bulk. The author notes that SquareTest raised coverage from 26 % to 55 % on a ten‑year‑old codebase.

Step 4 – Manual adjustments cover common pitfalls: mocking static methods (using mockStatic ), self‑invocation (using @Spy and doReturn ), final classes (mocking Method ), and multiple calls with different results (using when(...).thenReturn(...) sequences). Representative snippets are included throughout the article.

Step 5 – JSON‑based test replay : Record production request/response JSON and replay it in unit tests via a utility class based on json‑path . Example utility code:

public class JsonReadUtil {
public
T readJson(String filePath, String jsonPath, Class
clazz) throws Exception {
File file = new File(Objects.requireNonNull(this.getClass().getResource("/" + filePath)).toURI());
DocumentContext ctx = JsonPath.parse(file);
Object read = ctx.read(jsonPath);
return read != null ? JSON.parseObject(JSON.toJSONString(read), clazz) : null;
}
// overloaded method with TypeReference omitted for brevity
}

Step 6 – Testing‑driven refactoring : Citing "Refactoring: Improving the Design of Existing Code", the article stresses that unit tests act as a safety net, documentation, and catalyst for modular, testable design. It recommends incremental refactoring, micro‑refactors for private methods, and applying design patterns.

Finally, the author lists practical notes (module ordering, Maven classifier for WAR projects, using any() for nullable wrapper arguments) and provides links to related reading material.