Code Testing Extensions

Java Extension

Language-specific guidance for Java test generation.

Rule #1: Investigate the Repo First

Before writing any test or running any command, read:

1. Existing tests — find *Test.java / *Tests.java / *IT.java (integration) files and copy their style (JUnit version, assertion library, mock library, lifecycle methods)

2. Build file — pom.xml (Maven), build.gradle / build.gradle.kts (Gradle), BUILD / BUILD.bazel (Bazel)

3. Java version — <maven.compiler.release>, sourceCompatibility, or toolchains block

4. Wrapper scripts — always prefer ./mvnw or ./gradlew over a system-installed Maven/Gradle so you match the project's pinned version

Use whatever framework the repo already uses (JUnit 4, JUnit 5/Jupiter, TestNG). Do not migrate to a different framework as a side effect of writing tests.

Build Tool Detection

If both pom.xml and build.gradle exist, pick the one used by CI.

Build Commands

• Use -q (Maven) / --console=plain (Gradle) to reduce output noise

• For Gradle, prefer --no-daemon only in CI; locally the daemon makes incremental builds far faster

Test Commands

• Surefire runs unit tests (*Test.java); Failsafe runs integration tests (*IT.java) — do not put long integration tests under Surefire

• Gradle's --tests accepts wildcards: --tests "*MyMethod*"

• Use --rerun-tasks (Gradle) or -DforkCount=... (Surefire) only when troubleshooting cache issues

Lint Command

Use the repo's existing lint task first. Otherwise check for:

• Checkstyle (checkstyle.xml, <plugin>checkstyle</plugin>) → ./mvnw checkstyle:check or ./gradlew checkstyleMain

• Spotless (spotless block / plugin) → ./mvnw spotless:apply or ./gradlew spotlessApply

• ErrorProne / NullAway → integrated into compilation; run a normal build

• google-java-format / palantir-java-format → use the repo's configured formatter

Never disable existing checks in the test files you generate.

Project Layout and Imports

Maven/Gradle conventional layout:

src/
├── main/java/com/example/foo/Bar.java
├── main/resources/
├── test/java/com/example/foo/BarTest.java
└── test/resources/

• Test classes must mirror the production class's package to access package-private members

• Avoid wildcard imports unless the repo already uses them — match the explicit imports shown in the templates below

• For JUnit 5: import org.junit.jupiter.api.Test (and other annotations as needed) and org.junit.jupiter.api.Assertions.assertEquals etc. as static imports

• For JUnit 4: import org.junit.Test, org.junit.Before, etc., and org.junit.Assert.assertEquals etc. as static imports

Test Framework Detection

Argument order matters: JUnit/AssertJ use (expected, actual); TestNG uses (actual, expected). Reversing them produces confusing failure messages.

JUnit 5 Template

package com.example.foo;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class CalculatorTest {

    @Test
    @DisplayName("add returns sum of two positive numbers")
    void add_positiveNumbers_returnsSum() {
        Calculator sut = new Calculator();
        assertEquals(5, sut.add(2, 3));
    }

    @ParameterizedTest
    @CsvSource({
        "2, 3, 5",
        "-1, 1, 0"
    })
    void add_validInputs_returnsSum(int a, int b, int expected) {
        assertEquals(expected, new Calculator().add(a, b));
    }

    @Test
    void divide_byZero_throws() {
        Calculator sut = new Calculator();
        assertThrows(ArithmeticException.class, () -> sut.divide(1, 0));
    }
}

Common Errors

Mocking Rules

• Use whatever the repo already uses: Mockito (most common), EasyMock, JMockit, or hand-written fakes

• For JUnit 5 + Mockito, use @ExtendWith(MockitoExtension.class) with @Mock / @InjectMocks fields

• For JUnit 4 + Mockito, use @RunWith(MockitoJUnitRunner.class) or MockitoAnnotations.openMocks(this) in @Before

• Use when(mock.method(...)).thenReturn(...) for stubs and verify(mock).method(...) for interactions

• Use ArgumentCaptor to assert on complex argument values rather than over-specifying matchers

• Prefer constructor injection so production code stays testable without @InjectMocks

• If a test needs more than 3 mocks, flag it as a design smell

Spring Boot

If the repo uses Spring Boot:

• @SpringBootTest loads the full context — slow; use only when needed

• Slice tests are faster: @WebMvcTest, @DataJpaTest, @JsonTest

• Use @MockBean (Spring) only inside Spring tests; in plain unit tests use @Mock

• Use @Testcontainers for real-DB integration tests if the repo already has it on the classpath

Dependency Installation (Last Resort)

Only add dependencies after investigation confirms they are missing.

Maven (pom.xml):

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.10.2</version>
    <scope>test</scope>
</dependency>

Gradle (build.gradle.kts):

testImplementation("org.junit.jupiter:junit-jupiter:5.10.2")
testRuntimeOnly("org.junit.platform:junit-platform-launcher")

If the repo uses BOMs (<dependencyManagement> or Gradle platforms), reuse them — don't pin a different version than the BOM publishes.

Skip Coverage Tools

Do not configure or run coverage tools (JaCoCo, Cobertura, OpenClover). Coverage is measured separately by the evaluation harness.