Skip to content

Known Limitations

This document lists known target-specific limitations and recommended workarounds when writing end-to-end tests with Parikshan.

iOS Focus Contamination

Symptom

Text input actions (input(...)) can hang or fail during full test suite execution, specifically on text fields without a Modifier.testTag that rely on coordinate-based fallbacks.

Root Cause

Compose Multiplatform for iOS coordinates its custom keyboard and input logic via an internal IntermediateTextInputUIView. When executing sequential tests across multiple suites, focus state transitions can leak the first responder status, causing the main parent view (OverlayInputView or ComposeView) to retain focus and drop key events.

Workaround

Call relaunchApp() to reset the native window hierarchy and focus state before executing complex overlay text input scenarios on iOS.

You can reference our implementation of this workaround in OverlayIntegrationTest.kt:

if (isIos()) {
  relaunchApp() 
  navigateToSection("nav_overlay_playground")
  assertVisible("overlay_playground_screen")
}

Testing Sliders

Limitation

Programmatic value injection (e.g. directly setting a value) is not supported for standard Compose Slider components.

Cause

Compose Multiplatform's Slider does not expose semantic properties (like ProgressBarRangeInfo) in a way that allows direct value modification across all platform targets.

You can reference our slider integration test implementation in FormIntegrationTest.kt.

Locate the slider's bounding box, execute a coordinate-based horizontal drag gesture along the track, and verify the resulting value using a tolerance range (e.g. ±5%) to absorb layout, padding, and gesture velocity shifts.

// Drag slider to 80% of its track width
dragSlider("form_slider", 0.8f)

// Verify the value falls within a stable range (75% to 85%) to absorb gesture jitter
waitFor(Selector.Text("Range Selector:"))
val labelNode = resolveVisibleNode(Selector.Text("Range Selector:"))
val percentage = Regex("Range Selector: (\\d+)%").find(labelNode.text ?: "")
    ?.groupValues?.get(1)?.toIntOrNull() ?: 0
assert(percentage in 75..85)

Method B: Calibrated Coordinate Calculation (Exact but Risky)

Calculate exact drag coordinates by offsetting the bounding box width by the slider's internal track padding and thumb radius, then perform a precise drag gesture. While this can target exact values, it is highly sensitive to target-specific screen densities and layout dimension variances, making it prone to breakage across different targets.

No Auto-Scrolling to Off-Screen Targets

Symptom

Attempting to interact with (e.g. click(...), input(...)) or assert on (e.g. assertVisible(...)) an element that is rendered off-screen (inside a LazyColumn, LazyRow, or scrollable Column) fails with a target visibility or resolution timeout error.

Root Cause

Unlike testing frameworks that automatically attempt to scroll container viewports when an element is off-screen, Parikshan does not auto-scroll. This design keeps execution latencies under 10ms by avoiding repeated remote semantics tree traversal and layout calculations.

Workaround

Use scrollUntilVisible to programmatically scroll the container layout and bring the target element into view before performing actions or assertions:

// Scroll container "product_feed" until target "purchase_button" is visible
scrollUntilVisible(containerTag = "product_feed", targetTag = "purchase_button")
click("purchase_button")

Physical iOS Device Support

Limitation

Direct E2E test execution on physical iOS devices is not supported. Tests must be executed on local macOS iOS Simulators.

Cause

The host-side IosRemoteDriver uses the Apple Xcode command-line utility xcrun simctl to manage application lifecycle states (such as relaunchApp()) and capture execution video recordings (simctl io recordVideo). Since simctl is strictly a local simulator tool, these calls fail when targeting physical iOS hardware.

Workaround

Ensure your execution targets a booted iOS Simulator UDID or device name:

# Target-specific task
./gradlew :sample:composeApp:e2eIosTest -Dparikshan.ios.udid="YOUR_SIMULATOR_UDID"

# Unified test runner
./gradlew e2eTest --targets=ios --ios-device="YOUR_SIMULATOR_UDID"

Kotlin/JS Target Support

Limitation

E2E test execution on the legacy Kotlin/JS (js) target is not supported. Web-based E2E tests must target WebAssembly (wasmJs).

Cause

Parikshan's web automation infrastructure relies on Playwright browser hooks and Wasm canvas rendering semantics compiled specifically for the Compose Multiplatform WebAssembly target.

Workaround

Configure your web application target as wasmJs when running end-to-end tests:

# Target-specific task
./gradlew :sample:composeApp:e2eWasmTest

# Unified test runner
./gradlew e2eTest --targets=wasm

Host JVM Target Requirement

Limitation

Compose Multiplatform projects targeting WebAssembly (wasmJs) or iOS (iosArm64, iosSimulatorArm64, iosX64) require at least one JVM/Desktop target (such as jvm() or jvm("desktop")) or an Android target declared in build.gradle.kts to execute host-driven E2E tests.

Cause

Parikshan is a host-driven automation framework. The test runner (e2eTest, e2eWasmTest, e2eIosTest) executes on your host machine inside a JUnit 5 (JVM) process to orchestrate Chromium via Playwright or iOS Simulators via HTTP.

When a project is configured exclusively for Wasm and/or iOS without a JVM target, Kotlin Multiplatform produces only .wasm and iOS native Mach-O binaries—no Java .class bytecode is generated for commonTest.