一键在 Manus 中运行任何 Skill

kotlin-test-extensions-boilerplate

星标3

分支1

更新时间2026年4月14日 17:25

Use this skill when Kotlin test code contains duplicated setup or helper logic repeated at least 3 times. Create focused Kotlin extension functions (or small helper functions) to remove repetition while preserving test behavior and readability.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

upeter

upeter/kotlin-for-testing

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Goal

Extract repeated Kotlin test plumbing into small extension/helper functions so tests stay focused on intent.

Trigger threshold: apply this skill when the same pattern appears 3+ times.

Default Procedure

Scan Kotlin test files and identify duplicated code blocks repeated 3+ times.
Group duplicates by kind (data creation, assertion setup, fixture wiring, HTTP setup, response parsing, coroutine helpers, transactional helpers).
For each group, extract the smallest reusable unit:
- extension function when behavior belongs to a type,
- top-level helper when no receiver type is natural.
Keep defaults for common values, but allow explicit overrides.
Replace duplicated call sites with the new utility.
Remove dead imports/helpers and keep behavior-identical.

Use extraction and naming rules from references/patterns.md.

Boundaries

Apply this skill to test code only.
Do not change endpoint behavior or assertion meaning.
Keep extensions small and composable; avoid large helper methods that hide important assertions.
Do not extract code that appears fewer than 3 times unless requested.

Gotchas

Prefer extension functions only when a receiver type makes the API clearer.
Keep helpers narrow: one responsibility per function.
Avoid over-abstraction: if extraction harms readability at call sites, keep inline.
Preserve assertion semantics exactly (order-sensitive vs order-insensitive, nullability checks, exception checks).
Name helpers by intent, not implementation details.

Common Refactor Example

Before:

val speakerA = createSpeakerRequest(name = "Ada")
val speakerB = createSpeakerRequest(name = "Grace")
val speakerC = createSpeakerRequest(name = "Linus")

val savedA = speakerService.createSpeaker(speakerA)
val savedB = speakerService.createSpeaker(speakerB)
val savedC = speakerService.createSpeaker(speakerC)

After:

fun SpeakerService.createSpeakers(vararg requests: CreateSpeakerRequest): List<SpeakerDto> =
    requests.map(::createSpeaker)

val (savedA, savedB, savedC) = speakerService.createSpeakers(
    createSpeakerRequest(name = "Ada"),
    createSpeakerRequest(name = "Grace"),
    createSpeakerRequest(name = "Linus")
)

Validation Loop

Confirm each extracted helper replaces code repeated 3+ times.
Confirm call sites are shorter and still explicit about test intent.
Run tests that use the extracted helpers.
If behavior or semantics changed, revert and re-extract more narrowly.
Stop only when tests pass and readability improves.

Output Style

When reporting completion, include:

utility file(s) added or updated,
extension functions introduced or changed,
representative test files refactored to use them.

同仓库更多 Skills

同仓库

java-test-to-kotlin-supercharged

upeter/kotlin-for-testing

Use this skill to convert a Java test into an equivalent Kotlin test. Reuse existing Kotlin test infrastructure by default, preserve behavior, and verify with focused test commands.

2026-04-143

kotlin-data-class-from-java-records

upeter/kotlin-for-testing

Use this skill when converting Java record DTOs or request/response models to Kotlin data classes that remain Java-friendly. Always add @JvmRecord, map nullability correctly, keep related domain models in the same Kotlin file, and add only safe defaults (prefer emptyList() or null, not generic String defaults).

2026-04-143

kotest-from-assertj

upeter/kotlin-for-testing

Use this skill when converting AssertJ assertions in Kotlin tests to Kotest matcher DSL. Apply it to Kotlin test files, preserve assertion semantics, and keep the test intent unchanged. Do not use this skill for JUnit assertEquals/assertNotNull migrations.

2026-04-143

kotest-from-junit-assertions

upeter/kotlin-for-testing

Use this skill when converting Kotlin tests from JUnit assertions like assertEquals, assertNotNull, assertNull, assertTrue, assertFalse, and assertThrows to Kotest matcher DSL. Apply it to Kotlin test files and preserve behavior. Do not use this skill for AssertJ chain conversions.

2026-04-143

typesafe-test-data-dsl

upeter/kotlin-for-testing

Use this skill when implementing a type-safe Kotlin test data DSL for a selected subset of domain objects. Apply when tests need readable object graph construction and assembly (not just object creation). Ask for or infer the exact domain subset and build only that subset.

2026-04-143

kotlin-object-mother-default-args

upeter/kotlin-for-testing

Use this skill when creating Kotlin Object Mother factory functions for test data objects (requests, DTOs, entities). Create Kotlin methods with default arguments for common values, nullable types for optional properties, and required non-null parameters without defaults for mandatory properties.

2026-04-143

name	kotlin-test-extensions-boilerplate
description	Use this skill when Kotlin test code contains duplicated setup or helper logic repeated at least 3 times. Create focused Kotlin extension functions (or small helper functions) to remove repetition while preserving test behavior and readability.

Goal

Extract repeated Kotlin test plumbing into small extension/helper functions so tests stay focused on intent.

Trigger threshold: apply this skill when the same pattern appears 3+ times.

Default Procedure

Scan Kotlin test files and identify duplicated code blocks repeated 3+ times.
Group duplicates by kind (data creation, assertion setup, fixture wiring, HTTP setup, response parsing, coroutine helpers, transactional helpers).
For each group, extract the smallest reusable unit:
- extension function when behavior belongs to a type,
- top-level helper when no receiver type is natural.
Keep defaults for common values, but allow explicit overrides.
Replace duplicated call sites with the new utility.
Remove dead imports/helpers and keep behavior-identical.

Use extraction and naming rules from references/patterns.md.

Boundaries

Apply this skill to test code only.
Do not change endpoint behavior or assertion meaning.
Keep extensions small and composable; avoid large helper methods that hide important assertions.
Do not extract code that appears fewer than 3 times unless requested.

Gotchas

Prefer extension functions only when a receiver type makes the API clearer.
Keep helpers narrow: one responsibility per function.
Avoid over-abstraction: if extraction harms readability at call sites, keep inline.
Preserve assertion semantics exactly (order-sensitive vs order-insensitive, nullability checks, exception checks).
Name helpers by intent, not implementation details.

Common Refactor Example

Before:

val speakerA = createSpeakerRequest(name = "Ada")
val speakerB = createSpeakerRequest(name = "Grace")
val speakerC = createSpeakerRequest(name = "Linus")

val savedA = speakerService.createSpeaker(speakerA)
val savedB = speakerService.createSpeaker(speakerB)
val savedC = speakerService.createSpeaker(speakerC)

After:

fun SpeakerService.createSpeakers(vararg requests: CreateSpeakerRequest): List<SpeakerDto> =
    requests.map(::createSpeaker)

val (savedA, savedB, savedC) = speakerService.createSpeakers(
    createSpeakerRequest(name = "Ada"),
    createSpeakerRequest(name = "Grace"),
    createSpeakerRequest(name = "Linus")
)

Validation Loop

Confirm each extracted helper replaces code repeated 3+ times.
Confirm call sites are shorter and still explicit about test intent.
Run tests that use the extracted helpers.
If behavior or semantics changed, revert and re-extract more narrowly.
Stop only when tests pass and readability improves.

Output Style

When reporting completion, include:

utility file(s) added or updated,
extension functions introduced or changed,
representative test files refactored to use them.