From idea-to-code
Defines test types (unit, integration, component, end-to-end), source sets, execution commands, and JUnit 5 structure for Java Gradle projects. Useful for TDD and test running tasks.
npx claudepluginhub humansintheloop-dev/humansintheloop-dev-workflow-and-tools --plugin idea-to-codeThis skill uses the workspace's default tool permissions.
This skill defines what a "test" is and how tests are executed for this Java project.
Provides JUnit 5 best practices for Java unit tests: setup, AAA pattern, parameterized tests, assertions, Mockito mocking, and organization.
Guides JUnit 4/5 unit testing for Java/Kotlin with annotations (@Test, @BeforeEach), assertions, lifecycle methods, Mockito mocking, and Maven/Gradle setup.
Implements, configures, and debugs JUnit extensions including custom extensions, rules, and conditional test execution in Java projects.
Share bugs, ideas, or general feedback.
This skill defines what a "test" is and how tests are executed for this Java project. It is designed to be used together with a TDD skill that determines when tests must run.
Language: Java
Test framework: JUnit 5 (Jupiter)
Detailed test output: XML files under build/test-results/<testType>/TEST-*.xml
IMPORTANT: NEVER write test scripts that use gradlew bootRun. Direct testing of Java applications done using ./gradlew test/check only.
This project uses multiple test types with separate source sets, executed in order:
| Test Type | Task | Source Directory | Purpose |
|---|---|---|---|
| Unit | ./gradlew test | src/test/java | Fast, isolated tests with mocked dependencies |
| Integration | ./gradlew integrationTest | src/integrationTest/java | Tests with real external systems (databases, message brokers) via testcontainers |
| Component | ./gradlew componentTest | src/componentTest/java | Single service tested as a Docker container |
| End-to-End | ./gradlew endToEndTest | src/endToEndTest/java | Full application with multiple services |
test → integrationTest → componentTest → endToEndTest
All test types are wired to the check task. Running ./gradlew check executes all test types in order.
A test in this project is:
@org.junit.jupiter.api.TestExamples of valid test locations:
src/test/java/com/example/MyServiceTest.java (unit test)src/integrationTest/java/com/example/MyRepositoryIntegrationTest.java (integration test)src/componentTest/java/com/example/MyServiceComponentTest.java (component test)src/endToEndTest/java/com/example/OrderWorkflowE2ETest.java (end-to-end test)JUnit 5 assertions (e.g., Assertions.assertEquals, assertThrows) should be used.
No Kotlin and no JUnit 4 are present in this project.
Tests are run incrementally, progressing from fast/isolated to slow/integrated:
TDD Loop: Run unit tests frequently during development
./gradlew test
After unit tests pass: Run integration tests
./gradlew integrationTest
After integration tests pass: Run component tests
./gradlew componentTest
Before commit/PR: Run all tests
./gradlew check
This progression provides fast feedback during development while ensuring full coverage before committing.
./gradlew test # Unit tests only
./gradlew integrationTest # Integration tests only
./gradlew componentTest # Component tests only
./gradlew endToEndTest # End-to-end tests only
./gradlew check # All test types in order
All commands must be run from the project root (the directory containing gradlew).
Do not use the --no-daemon flag with Gradle commands unless specifically troubleshooting daemon issues. The Gradle daemon improves build performance by keeping the JVM warm between builds.
Use ./gradlew build, not ./gradlew clean build. Gradle's incremental build correctly detects changes. Only use clean when:
When creating a standalone Gradle project, use the gradle wrapper command to generate wrapper files instead of copying them from another project:
cd new-project-directory
gradle wrapper --gradle-version 8.11.1
This is cleaner than copying gradle/, gradlew, and gradlew.bat files and avoids permission issues.
Do not use output filtering with Gradle commands (no | tail, | head, or 2>&1 redirection). Gradle's console output is already concise - just task names and pass/fail status. Verbose test output (Hibernate SQL, Spring Boot logs, etc.) is captured in TEST-*.xml files, not streamed to the console.
./gradlew check to verify changes - this runs all test types (unit, integration, component tests)./gradlew test only when specifically running unit tests in a TDD loop./gradlew test only runs unit tests and misses integration/component testsFor any code modification task (refactoring, bug fixes, new features):
./gradlew build passes (includes all tests)When performing refactoring tasks (renaming classes, methods, moving files, changing signatures), always run the full test suite (./gradlew check) without excluding any test categories. Refactoring can break:
Only exclude test categories when explicitly instructed by the user or when debugging a specific test failure.
Exit code meaning:
The console output of Gradle indicates only overall success or failure, not individual test results.
When ./gradlew build succeeds (BUILD SUCCESSFUL), that is authoritative proof that all tests passed. Do not:
TEST*.xml and HTML reports are for human debugging, not for Claude verification.
Detailed per-test results are located in test-type-specific directories:
build/test-results/test/TEST-*.xml # Unit tests
build/test-results/integrationTest/TEST-*.xml # Integration tests
build/test-results/componentTest/TEST-*.xml # Component tests
build/test-results/endToEndTest/TEST-*.xml # End-to-end tests
Each XML file corresponds to a test class and contains:
<testsuite> metadata such as total tests and failures<testcase classname="..." name="..."> elements<failure> elements that contain the failure message and stack trace snippetThe agent must extract:
This information must be used to explain why tests failed and guide the next RED → GREEN change.
The TDD skill uses an Evidence block with fields:
tests: pass | fail | not-runlast_output: <text>This Test Runner skill defines how to populate those fields.
When tests pass:
tests: passlast_output should mention that ./gradlew test exited with code 0When tests fail:
tests: faillast_output should mention that ./gradlew test exited with a non-zero codebuild/test-results/test/) and describe the failing test(s)When tests cannot run (environment error):
tests: not-runlast_output should say that Gradle could not be executed./gradlew checkbuild/test-results/<testType> to identify failing testsNEVER delete or remove tests to make a build pass. If tests fail:
Deleting tests hides broken functionality and is never an acceptable solution.
NEVER ignore test failures. When tests fail:
When a test fails (whether from pre-commit hook, CI, or manual run):
Never assume a fix is correct without running the test to verify.
@Test methods in Java only./gradlew test (unit tests only)./gradlew check (all test types)build/test-results/<testType>/TEST-*.xml