unit-testing_skill

Overview

This skill is a practical guide for writing unit tests in a Kotlin-based CI platform using JUnit 5 and MockK. It covers test base setup, mock creation patterns, naming conventions, test organization, coverage expectations, and TDD workflows. The content focuses on concrete examples and rules to make unit tests reliable and maintainable.

How this skill works

The skill inspects common unit-test scenarios for service and DAO layers and shows how to mock external dependencies with MockK, use a shared test base providing DSLContext and ObjectMapper, and apply the Arrange-Act-Assert pattern. It explains stubbing behaviors, spy vs relaxed mocks, verification and exception assertions, and organizing tests with nested classes and descriptive names. It also provides a checklist to validate tests before committing.

When to use it

• When writing Service or DAO layer unit tests in Kotlin projects.
• When you need to mock external dependencies like DAOs, Redis, or Spring beans.
• When verifying business logic, edge cases, and error handling.
• During Test-Driven Development to drive design and coverage.
• When increasing or monitoring test coverage for critical modules.

Best practices

• Inherit the shared test base to get dslContext and objectMapper consistently.
• Follow AAA (Arrange-Act-Assert) and use clear, intent-revealing test names.
• Mock all external dependencies; prefer relaxed mocks only where defaults are safe.
• Cover both success and failure scenarios; assert thrown exceptions and error codes.
• Use builders or resource JSON to construct test data and keep tests readable.

Example use cases

• Unit testing a PipelineService method that loads a pipeline by ID and validating DAO interactions.
• Mocking Redis script results with conditional answers to simulate different return types.
• Spying a service to verify private-call behavior while keeping real logic for unmocked methods.
• Using nested test classes to group behaviors like 'exists' vs 'not found' cases.
• Driving a new feature via TDD: write failing tests, implement logic, then refactor.