Generate UI tests for FOSMVVM SwiftUI views using XCTest and FOSTestingUI. Covers accessibility identifiers, ViewModelOperations, and test data transport.
Instrucciones de origen · Vista previa de solo lectura
name
fosmvvm-ui-tests-generator
description
Generate UI tests for FOSMVVM SwiftUI views using XCTest and FOSTestingUI. Covers accessibility identifiers, ViewModelOperations, and test data transport.
finalclassMyDisplayViewUITests: MyAppViewModelViewTestCase<
MyDisplayViewModel,
MyDisplayViewStubOps
> {
// Only test UI state, no operation verification
}
The view itself doesn't need:
repaintToggle state
.testDataTransporter() modifier
operations property
toggleRepaint() function
Just add .uiTestingIdentifier() to elements you want to verify.
Test Categories
UI State Tests
Verify that the UI displays correctly based on ViewModel state:
Verify that user interactions invoke the correct operations:
functestSubmitButtonInvokesOperation() asyncthrows {
let app =try presentView(configuration: .requireAuth())
app.submitButton.tap()
let stubOps =try viewModelOperations()
XCTAssertTrue(stubOps.submitCalled)
XCTAssertFalse(stubOps.cancelCalled)
}
Navigation Tests
Verify navigation flows work correctly:
functestNavigationToDetailView() asyncthrows {
let app =try presentView()
app.itemRow.tap()
XCTAssertTrue(app.detailView.exists)
}
When to Use This Skill
Adding UI tests for a new ViewModelView
Setting up UI test infrastructure for a FOSMVVM project
Following an implementation plan that requires test coverage
Validating user interaction flows
What This Skill Generates
Initial Setup (once per project)
File
Location
Purpose
{ProjectName}ViewModelViewTestCase.swift
Tests/UITests/Support/
Base test case for all UI tests
XCUIElement.swift
Tests/UITests/Support/
Helper extensions for XCUIElement
Per ViewModelView
File
Location
Purpose
{ViewName}ViewModelOperations.swift
Sources/{ViewModelsTarget}/{Feature}/
Operations protocol and stub (if view has interactions)
{ViewName}UITests.swift
Tests/UITests/Views/{Feature}/
UI tests for the view
Note: Views without user interactions use an empty operations file with just the protocol and minimal stub.
Project Structure Configuration
Placeholder
Description
Example
{ProjectName}
Your project/app name
MyApp, TaskManager
{ViewName}
The ViewModelView name (without "View" suffix)
TaskList, Dashboard
{Feature}
Feature/module grouping
Tasks, Settings
How to Use This Skill
Invocation:
/fosmvvm-ui-tests-generator
Prerequisites:
View and ViewModel structure understood from conversation context
ViewModelOperations type identified (or confirmed as display-only)
Interactive elements and user flows discussed
Workflow integration:
This skill is typically used after implementing ViewModelViews. The skill references conversation context automatically—no file paths or Q&A needed. Often follows fosmvvm-swiftui-view-generator or fosmvvm-react-view-generator.
Pattern Implementation
This skill references conversation context to determine test structure:
Test Type Detection
From conversation context, the skill identifies:
First test vs additional test (whether base test infrastructure exists)
ViewModel type (from prior discussion or View implementation)
ViewModelOperations type (from View implementation or context)
Interactive vs display-only (whether operations need verification)
View Analysis
From requirements already in context:
Interactive elements (buttons, fields, controls requiring test coverage)
User flows (navigation paths, form submission, drag-and-drop)
State variations (enabled/disabled, visible/hidden, error states)
Operation triggers (which UI actions invoke which operations)
Infrastructure Planning
Based on project state:
Base test case (create if first test, reuse if exists)
XCUIElement extensions (helper methods for common interactions)
App bundle identifier (for launching test host)
Test File Generation
For the specific view:
Test class inheriting from base test case
UI state tests (verify display based on ViewModel)
Operation tests (verify user interactions invoke operations)
XCUIApplication extension with element accessors
View Requirements
Ensure test identifiers and data transport:
.uiTestingIdentifier() on all interactive elements
@State private var repaintToggle (if has operations)
.testDataTransporter() modifier (if has operations)
toggleRepaint() calls after operations (if has operations)
Context Sources
Skill references information from:
Prior conversation: View requirements, user flows discussed
View implementation: If Claude has read View code into context
ViewModelOperations: From codebase or discussion
Key Patterns
Test Configuration Pattern
Use TestConfiguration for tests that need specific app state:
functestWithSpecificState() asyncthrows {
let app =try presentView(
configuration: .requireAuth(userId: "123")
)
// Test with authenticated state
}
Element Accessor Pattern
Define element accessors in a private extension:
privateextensionXCUIApplication {
var submitButton: XCUIElement {
buttons.element(matching: .button, identifier: "submitButton")
}
var cancelButton: XCUIElement {
buttons.element(matching: .button, identifier: "cancelButton")
}
var firstItem: XCUIElement {
buttons.element(matching: .button, identifier: "itemButton").firstMatch
}
}
Operation Verification Pattern
After user interactions, verify operations were called:
functestDecrementButton() asyncthrows {
let app =try presentView(configuration: .requireDevice())
app.decrementButton.tap()
let stubOps =try viewModelOperations()
XCTAssertTrue(stubOps.decrementCalled)
XCTAssertFalse(stubOps.incrementCalled)
}
