Skip to main content

openswiftui-test-authoring

Route OpenSwiftUI test authoring and review work to the appropriate test guide while applying shared test-file conventions. Use for unit, compatibility, symbol-dual, or UI tests.

Aller à l'installation

Informations de source

Dépôt
OpenSwiftUIProject/OpenSwiftUI
Dernière activité de la source
13 septembre 2026 à 20:28
Langue détectée de SKILL.md
anglais
Étoiles
2 468
Forks
82

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Explorateur de fichiers
6 fichiers

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
openswiftui-test-authoring
description
Route OpenSwiftUI test authoring and review work to the appropriate test guide while applying shared test-file conventions. Use for unit, compatibility, symbol-dual, or UI tests.
# OpenSwiftUI Test Authoring ## Testing and Verification - Do not write tests for reversible, low-impact changes that only mirror the implementation. Add tests when they provide meaningful and necessary verification of observable behavior, boundaries, failures, or regression risks. - Run the narrowest relevant tests permitted by `AGENTS.md` and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task. ## Shared Conventions - Follow the organization and naming of the nearest tests in the same target. - Sort import declarations alphabetically by imported module name, preserving any attributes attached to each declaration. - Mark suites/tests that contain AI-generated Swift Testing tests with `.tags(.aigc)` on `@Suite` or `@Test`. Also add `import OpenSwiftUITestsSupport` if not imported yet. - In Swift Testing, prefer `@Test(arguments:)` when cases share the same test body. Keep different behaviors in separate tests. - Give argument collections explicit types when inference is ambiguous, especially tuple elements with integer literals or empty collections. A test parameter type does not necessarily constrain the macro's argument expression; use a typed fixture or values such as `UInt64(0b0011)` when needed. - Start each new Swift test file with this header, substituting the actual file name and the actual test target name: ```swift // // <FileName.swift> // <TestTargetName> ``` Leave one blank line after the target name. Do not add a closing decorative `//` line, and do not copy a target name from an unrelated example. ## Test-Type Guides Read only the guide that matches the requested test type: - Unit tests: [unit-tests.md](references/unit-tests.md) - Compatibility tests: [compatibility-tests.md](references/compatibility-tests.md) - Symbol-dual tests: [symbol-dual-tests.md](references/symbol-dual-tests.md) - UI tests: [ui-tests.md](references/ui-tests.md)
Voir sur GitHub