
Kotlin Testing
Follow Kotlin TDD with Kotest, MockK, coroutine tests, property-based checks, and Kover coverage reports on Gradle projects.
Overview
Kotlin Testing is an agent skill most often used in Ship (also Build backend) that guides TDD with Kotest, MockK, coroutine tests, property-based cases, and Kover coverage on Gradle Kotlin projects.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill kotlin-testingWhat is this skill?
- Seven-step TDD loop from target identification through Kover coverage verification
- Kotest spec styles: StringSpec, FunSpec, BehaviorSpec, and DescribeSpec for different scopes
- MockK patterns for dependencies, coroutine mocking, and argument capture
- Property-based testing guidance for Kotlin domains
- Coverage target of 80%+ via ./gradlew koverHtmlReport
- 7-step TDD workflow from identify target through Kover check
- 80%+ coverage target via ./gradlew koverHtmlReport
- Four Kotest spec styles referenced: StringSpec, FunSpec, BehaviorSpec, DescribeSpec
Adoption & trust: 4.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are adding or changing Kotlin production code without a consistent TDD recipe, spec style choice, or coverage threshold.
Who is it for?
Solo builders on Gradle Kotlin or KMP backends who want structured TDD and MockK-heavy unit tests before merging.
Skip if: Pure Java-only projects, UI snapshot-only testing with no JVM unit layer, or teams that forbid MockK in favor of manual fakes only.
When should I use this skill?
Writing new Kotlin functions or classes, adding test coverage to existing Kotlin code, implementing property-based tests, following TDD workflow in Kotlin projects, or configuring Kover for code coverage.
What do I get? / Deliverables
You get runnable Kotest specs with MockK isolation, a completed red-green-refactor cycle, and an HTML Kover report showing 80%+ coverage on the targeted module.
- Kotest spec files in the chosen style with MockK doubles
- Passing test suite after minimal implementation
- Kover HTML coverage report meeting the 80% guidance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Ship because the skill’s workflow centers on writing tests, running RED-GREEN-REFactor cycles, and proving coverage before release. Testing subphase matches Kotest specs, MockK isolation, and the explicit ./gradlew koverHtmlReport coverage gate.
Where it fits
Implement a new repository method with a failing Kotest spec before writing the SQL-backed implementation.
Backfill MockK-isolated unit tests on a legacy service module and gate merge on Kover HTML results.
Prepare a refactor PR where BehaviorSpec examples document expected domain rules for reviewers.
Add a regression spec after a production bug using the same seven-step TDD loop from the skill.
How it compares
Use as a Kotlin-native TDD playbook instead of generic JUnit examples that ignore Kotest styles and Kover.
Common Questions / FAQ
Who is kotlin-testing for?
Indie developers and small teams writing Kotlin services or apps who want the agent to follow Kotest, MockK, and Kover conventions rather than ad-hoc test snippets.
When should I use kotlin-testing?
Use it in Ship testing when adding coverage or fixing regressions, and in Build backend while implementing new Kotlin functions so tests are written before or alongside production code.
Is kotlin-testing safe to install?
The skill describes local test and Gradle commands only; review the Security Audits panel on this page before running suggested shell tasks in untrusted repos.
SKILL.md
READMESKILL.md - Kotlin Testing
# Kotlin Testing Patterns Comprehensive Kotlin testing patterns for writing reliable, maintainable tests following TDD methodology with Kotest and MockK. ## When to Use - Writing new Kotlin functions or classes - Adding test coverage to existing Kotlin code - Implementing property-based tests - Following TDD workflow in Kotlin projects - Configuring Kover for code coverage ## How It Works 1. **Identify target code** — Find the function, class, or module to test 2. **Write a Kotest spec** — Choose a spec style (StringSpec, FunSpec, BehaviorSpec) matching the test scope 3. **Mock dependencies** — Use MockK to isolate the unit under test 4. **Run tests (RED)** — Verify the test fails with the expected error 5. **Implement code (GREEN)** — Write minimal code to pass the test 6. **Refactor** — Improve the implementation while keeping tests green 7. **Check coverage** — Run `./gradlew koverHtmlReport` and verify 80%+ coverage ## Examples The following sections contain detailed, runnable examples for each testing pattern: ### Quick Reference - **Kotest specs** — StringSpec, FunSpec, BehaviorSpec, DescribeSpec examples in [Kotest Spec Styles](#kotest-spec-styles) - **Mocking** — MockK setup, coroutine mocking, argument capture in [MockK](#mockk) - **TDD walkthrough** — Full RED/GREEN/REFACTOR cycle with EmailValidator in [TDD Workflow for Kotlin](#tdd-workflow-for-kotlin) - **Coverage** — Kover configuration and commands in [Kover Coverage](#kover-coverage) - **Ktor testing** — testApplication setup in [Ktor testApplication Testing](#ktor-testapplication-testing) ### TDD Workflow for Kotlin #### The RED-GREEN-REFACTOR Cycle ``` RED -> Write a failing test first GREEN -> Write minimal code to pass the test REFACTOR -> Improve code while keeping tests green REPEAT -> Continue with next requirement ``` #### Step-by-Step TDD in Kotlin ```kotlin // Step 1: Define the interface/signature // EmailValidator.kt package com.example.validator fun validateEmail(email: String): Result<String> { TODO("not implemented") } // Step 2: Write failing test (RED) // EmailValidatorTest.kt package com.example.validator import io.kotest.core.spec.style.StringSpec import io.kotest.matchers.result.shouldBeFailure import io.kotest.matchers.result.shouldBeSuccess class EmailValidatorTest : StringSpec({ "valid email returns success" { validateEmail("user@example.com").shouldBeSuccess("user@example.com") } "empty email returns failure" { validateEmail("").shouldBeFailure() } "email without @ returns failure" { validateEmail("userexample.com").shouldBeFailure() } }) // Step 3: Run tests - verify FAIL // $ ./gradlew test // EmailValidatorTest > valid email returns success FAILED // kotlin.NotImplementedError: An operation is not implemented // Step 4: Implement minimal code (GREEN) fun validateEmail(email: String): Result<String> { if (email.isBlank()) return Result.failure(IllegalArgumentException("Email cannot be blank")) if ('@' !in email) return Result.failure(IllegalArgumentException("Email must contain @")) val regex = Regex("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$") if (!regex.matches(email)) return Result.failure(IllegalArgumentException("Invalid email format")) return Result.success(email) } // Step 5: Run tests - verify PASS // $ ./gradlew test // EmailValidatorTest > valid email returns success PASSED // EmailValidatorTest > empty email returns failure PASSED // EmailValidatorTest > email without @ returns failure PASSED // Step 6: Refactor if needed, verify tests still pass ``` ### Kotest Spec Styles #### StringSpec (Simplest) ```kotlin class CalculatorTest : StringSpec({ "add two positive numbers" { Calculator.