Feature Test

Feature Test

Generates a comprehensive test suite for a KMP feature: fixtures + DataSource + Repository + ViewModel + UI + integration tests, then runs them and produces a Kover coverage report.

Usage:

/feature-test login

The command itself orchestrates the work — there is no separate "test-orchestrator" agent.

Phase 1: Discovery (direct)

The command does this itself (no agent).

1.1 Detect namespaces

grep "namespace" feature/{featurename}/build.gradle.kts     # → PKG_PREFIX
grep "namespace" core/common/build.gradle.kts               # → CORE_COMMON_PKG
grep "namespace" core/data/build.gradle.kts                 # → CORE_DATA_PKG

1.2 Extract YAML context (not full code)

entities:   [{ name, fields }]
dataSource: { interface, implementation, methods }
repository: { interface, implementation, dependencies }
viewModel:  { class, dependencies, actions }
screen:     { composable, rootComposable, callbacks }

Workers receive these YAML slices — they do not re-read source files.

1.3 Add test dependencies (if missing)

Checks feature/{featurename}/build.gradle.kts for commonTest. If absent, adds:

// In plugins block (if not present):
alias(libs.plugins.kover)
alias(libs.plugins.mokkery)

// Added under sourceSets {...}:
commonTest {
    dependencies {
        implementation(libs.bundles.testing.common)  // kotlin-test, kotlinx-coroutines-test, turbine
        implementation(libs.compose.ui.test)
        implementation(libs.ktor.client.mock)
        implementation(libs.ktor.client.content.negotiation)
        implementation(libs.ktor.serialization.kotlinx.json)
        implementation(libs.ktor.client.resources)
    }
}

val desktopTest by getting {
    dependencies {
        implementation(compose.desktop.currentOs)
    }
}

Phase 2: Project Sync

The command uses AskUserQuestion to request a Gradle sync. Waits for confirmation before continuing — without sync, the test deps aren't on the classpath yet.

Phase 3: Spawn Agents

3.1 Fixtures — sequential, single Task call

Test-Fixtures runs alone; the orchestrator waits for completion. Every other agent depends on the fixtures.

3.2 Data layer — parallel (2 agents)

Both in the same message:

• Test-DataSource
• Test-Repository

3.3 Presentation + integration — parallel (3 agents)

All three in the same message:

• Test-ViewModel
• Test-UI — UI tests target ScreenRoot, not Screen
• Test-Integration

Max parallel: 3 agents (memory-safe).

Phase 4: Run Tests

./gradlew :feature:{featurename}:cleanDesktopTest :feature:{featurename}:desktopTest

Phase 5: Coverage

./gradlew :feature:{featurename}:koverHtmlReport

Parses feature/{featurename}/build/reports/kover/report.xml for line/branch coverage.

Phase 6: Summary

## Test Generation: {feature}

| Test | File |
|------|------|
| Fixtures   | .../fixtures/{Feature}Fixtures.kt |
| UiFixtures | .../fixtures/{Feature}UiFixtures.kt |
| DataSource | .../data/datasource/{Feature}RemoteDataSourceTest.kt |
| Repository | .../data/{Feature}RepositoryImplTest.kt |
| ViewModel  | .../presentation/{Feature}ViewModelTest.kt |
| UI         | .../presentation/ui/{Feature}ScreenTest.kt |
| Integration| .../integration/{Feature}IntegrationTest.kt |

**Tests:** PASSED / FAILED | **Coverage:** Line X% / Branch Y%

View: open feature/{featurename}/build/reports/kover/html/index.html

Execution Flow at a Glance

Phase 1: Read files → extract YAML
Phase 2: AskUserQuestion(sync) → WAIT
Phase 3.1: Task(fixtures) → WAIT
Phase 3.2: Task(datasource) + Task(repository) → WAIT (parallel)
Phase 3.3: Task(viewmodel) + Task(ui) + Task(integration) → WAIT (parallel)
Phase 4-6: Run tests → coverage → summary

Spec-Aware Testing

If .claude/docs/{featurename}/spec.md exists:

• The orchestrator extracts the FR-X.Y requirement scenarios
• Passes them to ViewModel / UI agents
• Maps test methods to spec requirements
• Reports spec coverage percentage in the summary

After Completion

./gradlew :feature:{featurename}:desktopTest
./gradlew :feature:{featurename}:desktopTest --tests "*ViewModelTest"
open   feature/{featurename}/build/reports/kover/html/index.html

Key Rules

1. The command does the discovery itself; no agent for Phase 1.
2. Adds test dependencies if missing (Phase 1.3).
3. Requests sync and waits (Phase 2).
4. Workers receive YAML summaries — they never read full source files.
5. Fixtures must complete before downstream agents spawn.
6. Max 3 parallel agents.
7. UI tests target ScreenRoot (the ViewModel-independent composable).

---

Back to Commands