FOSMVVM UI Tests Generator

Generate comprehensive UI tests for ViewModelViews in FOSMVVM applications.

Conceptual Foundation

For full architecture context, see FOSMVVMArchitecture.md | OpenClaw reference

UI testing in FOSMVVM follows a specific pattern that leverages:

• - FOSTestingUI framework for test infrastructure
• ViewModelOperations for verifying business logic was invoked
• Accessibility identifiers for finding UI elements
• Test data transporter for passing operation stubs to the app

CODEBLOCK0

Core Components

1. Base Test Case Class

Every project should have a base test case that inherits from ViewModelViewTestCase:

CODEBLOCK1

Key points:

• - Generic over ViewModel and INLINECODE2
• Wraps FOSTestingUI's presentView() with project-specific configuration
• Sets up bundle and app bundle identifier
• INLINECODE4 stops tests immediately on failure

2. Individual UI Test Files

Each ViewModelView gets a corresponding UI test file.

For views WITH operations:

CODEBLOCK2

For views WITHOUT operations (display-only):

Use an empty stub operations protocol:

CODEBLOCK3

When to use each:

• - With operations: Interactive views that perform actions (forms, buttons that call APIs, etc.)
• Without operations: Display-only views (cards, detail views, static content)

3. XCUIElement Helper Extensions

Common helpers for interacting with UI elements:

CODEBLOCK4

4. View Requirements

For views WITH operations:

CODEBLOCK5

For views WITHOUT operations (display-only):

CODEBLOCK6

Critical patterns (for views WITH operations):

• - @State private var repaintToggle = false for triggering test data transport
• INLINECODE6 modifier in DEBUG
• INLINECODE7 called after every operation invocation
• INLINECODE8 stored as property from INLINECODE9

Display-only views:

• - No repaintToggle needed
• No .testDataTransporter() modifier needed
• Just add .uiTestingIdentifier() to elements you want to test

ViewModelOperations: Optional

Not all views need ViewModelOperations:

Views that NEED operations:

• - Forms with submit/cancel actions
• Views that call business logic or APIs
• Interactive views that trigger app state changes
• Views with user-initiated async operations

Views that DON'T NEED operations:

• - Display-only cards or detail views
• Static content views
• Pure navigation containers
• Server-hosted views that just render data

For views without operations:

Create an empty operations file alongside your ViewModel:

CODEBLOCK7

Then use it in tests:

CODEBLOCK8

The view itself doesn't need:

• - repaintToggle state
• INLINECODE14 modifier
• INLINECODE15 property
• INLINECODE16 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:

CODEBLOCK9

Operation Tests

Verify that user interactions invoke the correct operations:

CODEBLOCK10

Navigation Tests

Verify navigation flows work correctly:

CODEBLOCK11

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
INLINECODE18	INLINECODE19	Base test case for all UI tests
INLINECODE20

Tests/UITests/Support/ | Helper extensions for XCUIElement |

Per ViewModelView

File	Location	Purpose
INLINECODE22	INLINECODE23	Operations protocol and stub (if view has interactions)
INLINECODE24

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
INLINECODE26	Your project/app name	INLINECODE27, INLINECODE28
INLINECODE29

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:

1. 1. Test class inheriting from base test case
2. UI state tests (verify display based on ViewModel)
3. Operation tests (verify user interactions invoke operations)
4. XCUIApplication extension with element accessors

View Requirements

Ensure test identifiers and data transport:

1. 1. .uiTestingIdentifier() on all interactive elements
2. INLINECODE36 (if has operations)
3. INLINECODE37 modifier (if has operations)
4. INLINECODE38 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:

CODEBLOCK12

Element Accessor Pattern

Define element accessors in a private extension:

CODEBLOCK13

Operation Verification Pattern

After user interactions, verify operations were called:

CODEBLOCK14

Orientation Setup Pattern

Set device orientation in setUp() if needed:

CODEBLOCK15

View Testing Checklist

All views:

• - [ ] .uiTestingIdentifier() on all elements you want to test

Views WITH operations (interactive views):

• - [ ] @State private var repaintToggle = false property
• [ ] .testDataTransporter(viewModelOps:repaintToggle:) modifier
• [ ] toggleRepaint() helper function
• [ ] toggleRepaint() called after every operation invocation
• [ ] operations stored from viewModel.operations in init

Views WITHOUT operations (display-only):

• - [ ] No repaintToggle needed
• [ ] No .testDataTransporter() needed
• [ ] No operations property needed
• [ ] operations stored from viewModel.operations in init

Common Test Patterns

Testing Async Operations

CODEBLOCK16

Testing Form Input

CODEBLOCK17

Testing Error States

CODEBLOCK18

File Templates

See reference.md for complete file templates.

Naming Conventions

Concept	Convention	Example
Base test case	INLINECODE53	INLINECODE54
UI test file

{ViewName}UITests | TaskListViewUITests | | Test method (UI state) | test{Condition} | testButtonEnabled | | Test method (operation) | test{Action} | testSubmitButton | | Element accessor | {elementName} | submitButton, emailTextField | | UI testing identifier | {elementName}Identifier or {elementName} | "submitButton", "emailTextField" |

See Also

• - Architecture Patterns - Mental models and patterns
• FOSMVVMArchitecture.md - Full FOSMVVM architecture
• fosmvvm-viewmodel-generator - For creating ViewModels
• fosmvvm-swiftui-app-setup - For app test host setup
• reference.md - Complete file templates

Version History

Version	Date	Changes
1.0	2026-01-23	Initial skill for UI tests
1.1

2026-01-24 | Update to context-aware approach (remove file-parsing/Q&A). Skill references conversation context instead of asking questions or accepting file paths. |