agentleFS
Sign inStart free
ControllableModelControllableModel/SWE-Skills-Bench/skills/junit5-testing/SKILL.md

junit5-testing

Skill8 starsChanged 26 days agoMITView on GitHub

Get best practices for JUnit 5 unit testing, including data-driven tests

The file

Show its rules and text

We split this skill into the rules it gives an agent

27 rules. About 0 are common, 7 are distinctive, and 20 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 20

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use a standard Maven or Gradle project structure.

    line 12
  2. Very specific:

    Place test source code in src/test/java.

    line 13
  3. Very specific:

    Use build tool commands to run tests: mvn test or gradle test.

    line 15
  4. Very specific:

    Test classes should have a Test suffix, e.g., CalculatorTest for a Calculator class.

    line 19
  5. Very specific:

    Use @Test for test methods.

    line 20
  6. Distinctive:

    Follow the Arrange-Act-Assert (AAA) pattern.

    line 21
  7. Very specific:

    Use @BeforeEach and @AfterEach for per-test setup and teardown.

    line 23
  8. Very specific:

    Use @BeforeAll and @AfterAll for per-class setup and teardown (must be static methods).

    line 24
  9. Very specific:

    Use @DisplayName to provide a human-readable name for test classes and methods.

    line 25
  10. Distinctive:

    Keep tests focused on a single behavior.

    line 29
  11. Distinctive:

    Avoid testing multiple conditions in one test method.

    line 30
  12. Very specific:

    Use @ParameterizedTest to mark a method as a parameterized test.

    line 36
  13. Very specific:

    Use @ValueSource for simple literal values (strings, ints, etc.).

    line 37
  14. Very specific:

    Use @MethodSource to refer to a factory method that provides test arguments as a Stream, Collection, etc.

    line 38
  15. Very specific:

    Use @CsvSource for inline comma-separated values.

    line 39
  16. Very specific:

    Use @CsvFileSource to use a CSV file from the classpath.

    line 40
  17. Very specific:

    Use @EnumSource to use enum constants.

    line 41
  18. Very specific:

    Use the static methods from org.junit.jupiter.api.Assertions (e.g., assertEquals, assertTrue, assertNotNull).

    line 45
  19. Very specific:

    Use assertThrows or assertDoesNotThrow to test for exceptions.

    line 47
  20. Distinctive:

    Use descriptive messages in assertions to provide clarity on failure.

    line 49
  21. Distinctive:

    Use a mocking framework like Mockito to create mock objects for dependencies.

    line 53
  22. Very specific:

    Use @Mock and @InjectMocks annotations from Mockito to simplify mock creation and injection.

    line 54
  23. Distinctive:

    Use interfaces to facilitate mocking.

    line 55
  24. Very specific:

    Use @Tag to categorize tests (e.g., @Tag("fast"), @Tag("integration")).

    line 60
  25. Very specific:

    Use @TestMethodOrder(MethodOrderer.OrderAnnotation.class) and @Order to control test execution order when strictly necessary.

    line 61
  26. Very specific:

    Use @Disabled to temporarily skip a test method or class, providing a reason.

    line 62
  27. Very specific:

    Use @Nested to group tests in a nested inner class for better organization and structure.

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

JUnit 5+ Best Practices

Your goal is to help me write effective unit tests with JUnit 5, covering both standard and data-driven testing approaches.

Project Setup

  • Use a standard Maven or Gradle project structure.
  • Place test source code in src/test/java.
  • Include dependencies for junit-jupiter-api, junit-jupiter-engine, and junit-jupiter-params for parameterized tests.
  • Use build tool commands to run tests: mvn test or gradle test.

Test Structure

  • Test classes should have a Test suffix, e.g., CalculatorTest for a Calculator class.
  • Use @Test for test methods.
  • Follow the Arrange-Act-Assert (AAA) pattern.
  • Name tests using a descriptive convention, like methodName_should_expectedBehavior_when_scenario.
  • Use @BeforeEach and @AfterEach for per-test setup and teardown.
  • Use @BeforeAll and @AfterAll for per-class setup and teardown (must be static methods).
  • Use @DisplayName to provide a human-readable name for test classes and methods.

Standard Tests

  • Keep tests focused on a single behavior.
  • Avoid testing multiple conditions in one test method.
  • Make tests independent and idempotent (can run in any order).
  • Avoid test interdependencies.

Data-Driven (Parameterized) Tests

  • Use @ParameterizedTest to mark a method as a parameterized test.
  • Use @ValueSource for simple literal values (strings, ints, etc.).
  • Use @MethodSource to refer to a factory method that provides test arguments as a Stream, Collection, etc.
  • Use @CsvSource for inline comma-separated values.
  • Use @CsvFileSource to use a CSV file from the classpath.
  • Use @EnumSource to use enum constants.

Assertions

  • Use the static methods from org.junit.jupiter.api.Assertions (e.g., assertEquals, assertTrue, assertNotNull).
  • For more fluent and readable assertions, consider using a library like AssertJ (assertThat(...).is...).
  • Use assertThrows or assertDoesNotThrow to test for exceptions.
  • Group related assertions with assertAll to ensure all assertions are checked before the test fails.
  • Use descriptive messages in assertions to provide clarity on failure.

Mocking and Isolation

  • Use a mocking framework like Mockito to create mock objects for dependencies.
  • Use @Mock and @InjectMocks annotations from Mockito to simplify mock creation and injection.
  • Use interfaces to facilitate mocking.

Test Organization

  • Group tests by feature or component using packages.
  • Use @Tag to categorize tests (e.g., @Tag("fast"), @Tag("integration")).
  • Use @TestMethodOrder(MethodOrderer.OrderAnnotation.class) and @Order to control test execution order when strictly necessary.
  • Use @Disabled to temporarily skip a test method or class, providing a reason.
  • Use @Nested to group tests in a nested inner class for better organization and structure.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free