Agent skill
test-application-service
Generate a pure mockk unit test (no Spring context) for an application-layer use-case service. Use when the user asks to "write tests for an application service", "test a use case", or "generate unit tests for a service". Follows the project's given/when/then pattern with `confirmVerified` after every verify block; uses domain test builders and fixed UUIDs; no Spring context required.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/test-application-service
SKILL.md
Skill: test-application-service
Generate a unit test for an application service (use case) following the project's established test patterns.
Pattern
Application service tests are pure unit tests using mockk. No Spring context required.
class YourServiceTest {
private val port = mockk<SomePort>()
private val underTest = YourService(port = port)
@Test
fun `describe behaviour`() {
// given: valid input and mocked port behaviour
every { port.method(any()) } returns value // or: just Runs
// when: the use case is executed
underTest.execute(command)
// then: the port is called with the expected arguments
verify { port.method(expected) }
confirmVerified(port)
}
}
See references/service-test-template.kt for the full annotated example (slot capture, multiple mocks).
IMPORTANT
- Mirror the class from the production-code with just a suffix
Test - Instantiate the service directly — no Spring context
mockk<Interface>()for each constructor dependencyconfirmVerified(mock)inline at the end of each test — not in@AfterEach- Stub Unit-returning methods with
just Runs; usereturns valueotherwise - One
@Testper distinct behaviour (happy path + exception if the service throws) - Use test builders from
domain/TestObjectBuilder.kt(e.g.testNewsletterSubscription()) - Fixed UUID strings for deterministic test data
- Structure each test with
// given: <what is set up>,// when: <the action>,// then: <what is verified>sections; omit the section comment when that phase is a single line - Backtick test names
Instructions
Step 1 – Read and identify
Read the service file at $ARGUMENTS and extract:
- Service class name and the use-case interface it implements
- Constructor dependencies (repository interfaces, outbound ports)
- Each public method: signature, what it calls, what it returns or throws
- Domain value types used (e.g.
SubscriptionId,NewsletterSubscription)
If no matching service was found, pause the execution and, ask the user to provide the path to the service
Also locate test builders. Look for functions in the test module and its domain package that build objects that are
used in the service.
If none exists, pause the execution as well.
Ask the user to provide or link to the builder(s)
Step 2 – Locate the test file
- Derive the test file path by replacing
src/main/kotlinwithsrc/test/kotlinin the service file path. - Keep the same package structure and class name, but append
Testas a suffix (e.g.SubscribeToNewsletterService→SubscribeToNewsletterServiceTest). - If the test file already exists at that path, open it and switch to fix mode.
- If it does not exist, proceed to generate a new file in Step 4.
Step 3 – Determine required test cases
- Write one happy-path test for each public method of the service.
- Add an exception test only when the service explicitly throws (e.g.
NoSuchElementException). - Keep the total number of tests to three or fewer.
- If more scenarios are applicable, list them and ask the user for permission before writing additional tests.
Step 4 – Generate or fix the test file
- Use
references/service-test-template.ktas a starting point - Use test builders from
domain/TestObjectBuilder.kt; fixed UUID strings - Backtick test names
Step 5 – Write, run, and report
- Write the file to the located path;
- Run all tests in the class via an appropriate Gradle command;
- Report the created or updated file path and a brief summary.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?