Kmp Swift Support Test Data

KMP Swift Support Test Data

Purpose

This skill helps maintain KmpTestData for KMP Swift support E2E UI tests in IntelliJ IDEA and Android Studio.

The goal is NOT broad language coverage.

The goal is:

• minimal and stable test fixtures,
• high-signal IDE scenarios,
• deterministic E2E UI tests,
• explicit Swift and Swift ↔ Kotlin cross-language behavior.

This skill should help generate or modify test data used by UI tests for Swift support and Swift ↔ Kotlin cross-language IDE features.

Examples include, but are not limited to:

• completion,
• highlighting,
• gutters,
• go to declaration,
• find usages,
• create file,
• navigation,
• symbol resolution,
• refactorings,
• quick fixes,
• inspections,
• code generation,
• imports,
• rename,
• usages/search,
• project/module integration.

Feature lists in this skill are examples, not limitations.

If the requested IDE feature is not listed, still apply the same principles:

• minimal fixture,
• stable UI anchors,
• clear expected IDE behavior,
• Swift-only and Swift ↔ Kotlin evaluation,
• README update when test data changes.

Core Principles

1. Optimize for E2E stability

All generated code must be optimized for:

• stable indexing,
• deterministic UI behavior,
• predictable symbol resolution,
• simple navigation targets,
• low ambiguity unless ambiguity is explicitly tested.

Avoid:

• unnecessary architecture,
• realistic app structure,
• large examples,
• unrelated declarations,
• generated noise.

2. Minimal fixture philosophy

Prefer:

• 1–3 tiny files,
• one focused scenario,
• one explicit IDE behavior,
• one stable assertion target.

Do NOT create:

• broad demo applications,
• many variants of the same feature,
• exhaustive language coverage.

The fixture should contain only code needed for the requested IDE behavior.

Examples of useful fixture elements:

• completion items,
• navigation targets,
• usages,
• gutter anchors,
• highlighting anchors,
• inspection/quick-fix anchors,
• refactoring anchors,
• generated-file targets,
• import/module-resolution anchors,
• cross-language declarations or usages.

Every symbol must exist for a reason.

3. Cross-language awareness

When a Swift-only scenario is requested, ALWAYS evaluate whether a Swift ↔ Kotlin cross-language variant should also be added.

Examples:

• Swift completion → also consider Kotlin declarations visible in Swift.
• Swift find usages → also consider usages crossing Swift/Kotlin boundary.
• Swift go to declaration → also consider navigation to Kotlin declarations.
• Swift gutters → also consider Swift → Kotlin inheritance/navigation gutters.
• Swift rename → also consider cross-language rename propagation.

Do NOT automatically generate cross-language fixtures if they add no IDE value.

But ALWAYS explicitly evaluate them.

Workflow

Before generating code, ALWAYS produce a short plan.

Use this format:

Feature under test:
IDE action under test:
Swift-only scenario:
Cross-language scenario:
Files to add/change:
Stable UI anchors:
Expected assertions:
Why this is minimal:

Only after the plan is accepted or logically complete should fixture code be generated.

Naming Rules

Use:

• short,
• explicit,
• searchable,
• stable names.

Good:

• CompletionSource
• CompletionConsumer
• CrossLanguageUsage
• SwiftNavigationTarget
• KotlinDeclarationTarget

Bad:

• Manager
• Helper
• MyClass
• DataProvider
• RepositoryImplFactory

Symbol names should help UI tests locate targets reliably.

File Organization Rules

Prefer:

• new focused files for new scenarios,
• isolated fixtures,
• minimal edits to existing fixtures.

Avoid:

• extending unrelated fixtures,
• mixing multiple IDE features in one file,
• large shared utility files.

Prefer feature-owned source files even when fixture code is structurally similar. Small intentional duplication is acceptable when it keeps E2E scenarios isolated and easier to debug.

Examples:

• SwiftCompletionSource.swift and SwiftGoToDeclarationSource.swift should stay separate.
• KotlinCompletionSource.kt and KotlinGoToDeclarationSource.kt should stay separate.

Only modify existing fixtures if:

• the requested feature logically belongs there,
• or the fixture already represents the same IDE behavior.

README Rules

When adding new fixtures:

• update README,
• document:
  • feature,
  • involved files,
  • IDE behavior,
  • important navigation anchors.

Keep README entries short and test-oriented.

Stability Rules

Prefer:

• explicit imports,
• explicit type names,
• explicit inheritance.

Avoid:

• implicit inference if it affects IDE behavior,
• random ordering dependencies,
• unrelated symbols with similar names.

Do not rely on:

• flaky indexing order,
• unresolved references,
• accidental completion ranking.

Existing Fixture Awareness

The repository already contains fixtures for:

• Swift cross-language super gutters UI tests in ../../iosApp/iosApp/swiftTestFixtures.
• Swift completion UI tests in ../../iosApp/iosApp/swiftTestFixtures.
• Kotlin declarations exported to Swift for completion UI tests in ../../shared/src/iosMain/kotlin/org/jetbrains/kmptestdata/kotlinTestFixtures.

Do not duplicate existing super gutter scenarios unless:

• extending coverage meaningfully,
• or testing a different IDE behavior.

Prefer reusing patterns and naming conventions from existing fixtures.

For completion fixtures:

• keep consumer functions as stable edit anchors,
• describe probes with Type: and Expect: comments,
• do not pre-create symbols that are meant to test "added after project open" behavior,
• place Kotlin declarations that specifically test Swift/iOS export behavior under iosMain,
• verify lookup item presence, not ranking.

Definition of Done

A generated fixture is complete only if:

• it is minimal,
• every symbol has a testing purpose,
• IDE behavior is obvious,
• navigation targets are stable,
• cross-language behavior was evaluated,
• README was updated,
• no unrelated complexity was added.

The ideal fixture is:

• tiny,
• explicit,
• deterministic,
• easy to debug in UI tests.