一键在 Manus 中运行任何 Skill

typesafe-test-data-dsl

星标3

分支1

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

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.

安装

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

在 Manus 中运行

来源

upeter

upeter/kotlin-for-testing

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

下载

在 Manus 中运行

Goal

Create a type-safe Kotlin DSL for test data that supports both:

constructing domain objects, and
assembling object graphs/relationships.

The DSL should cover only a focused subset of domain classes required by the target tests, not the entire domain model.

Scope First (Required)

Before coding, determine the exact DSL scope from tests or user input:

Identify the target test scenarios.
List candidate domain types used there.
Choose only the minimum subset needed.

Use references/scoping-template.md to define the explicit include/exclude list.

Default Implementation Procedure

Create a DSL entry point for the chosen aggregate (for example, talks { ... } or orders { ... }).
Add typed builder classes with @DslMarker to prevent receiver confusion.
Model required fields as mandatory in build() with clear requireNotNull errors.
Provide ergonomic helpers for relationships/assembly (for example, attach tags, add co-speakers, link parent/child entities).
Prevent invalid nesting or out-of-scope usage with explicit error methods or restricted API surface.
Return immutable snapshots from root builders (toList, copied sets/maps) so tests do not mutate internal DSL state accidentally.
Keep defaults practical for tests, but avoid hiding mandatory domain constraints.

Design Rules

Keep DSL API small and scenario-driven.
Favor readability over configurability.
Use domain names in DSL functions (talk, speaker, tag) only for in-scope types.
Do not generate a "DSL for everything".
Prefer one clear way to express each relationship.

Gotchas

Over-scoping is the main failure mode; only build what current tests need.
Builder-only patterns often construct objects but do not assemble relationships; include assembly operations explicitly.
Missing @DslMarker can cause accidental cross-scope mutation.
Ensure deterministic collection behavior when assertions rely on order.
Fail fast with helpful messages when required pieces are missing.

Validation Loop

Verify DSL usage in target tests reads clearly and reduces temporary variables.
Run tests that consume the DSL.
If a test requires unsupported structure, extend scope deliberately (update include/exclude list first).
Stop when DSL covers target scenarios without broadening into unrelated domain areas.

Output Style

When reporting work:

state which domain types are included,
state which related types are explicitly excluded,
summarize assembly features added,
note any invariants enforced by build().

同仓库更多 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

kotlin-test-extensions-boilerplate

upeter/kotlin-for-testing

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.

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	typesafe-test-data-dsl
description	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.

Goal

Create a type-safe Kotlin DSL for test data that supports both:

constructing domain objects, and
assembling object graphs/relationships.

The DSL should cover only a focused subset of domain classes required by the target tests, not the entire domain model.

Scope First (Required)

Before coding, determine the exact DSL scope from tests or user input:

Identify the target test scenarios.
List candidate domain types used there.
Choose only the minimum subset needed.

Use references/scoping-template.md to define the explicit include/exclude list.

Default Implementation Procedure

Create a DSL entry point for the chosen aggregate (for example, talks { ... } or orders { ... }).
Add typed builder classes with @DslMarker to prevent receiver confusion.
Model required fields as mandatory in build() with clear requireNotNull errors.
Provide ergonomic helpers for relationships/assembly (for example, attach tags, add co-speakers, link parent/child entities).
Prevent invalid nesting or out-of-scope usage with explicit error methods or restricted API surface.
Return immutable snapshots from root builders (toList, copied sets/maps) so tests do not mutate internal DSL state accidentally.
Keep defaults practical for tests, but avoid hiding mandatory domain constraints.

Design Rules

Keep DSL API small and scenario-driven.
Favor readability over configurability.
Use domain names in DSL functions (talk, speaker, tag) only for in-scope types.
Do not generate a "DSL for everything".
Prefer one clear way to express each relationship.

Gotchas

Over-scoping is the main failure mode; only build what current tests need.
Builder-only patterns often construct objects but do not assemble relationships; include assembly operations explicitly.
Missing @DslMarker can cause accidental cross-scope mutation.
Ensure deterministic collection behavior when assertions rely on order.
Fail fast with helpful messages when required pieces are missing.

Validation Loop

Verify DSL usage in target tests reads clearly and reduces temporary variables.
Run tests that consume the DSL.
If a test requires unsupported structure, extend scope deliberately (update include/exclude list first).
Stop when DSL covers target scenarios without broadening into unrelated domain areas.

Output Style

When reporting work:

state which domain types are included,
state which related types are explicitly excluded,
summarize assembly features added,
note any invariants enforced by build().