cometchat-ios-testing

Ground truth: CometChatUIKitSwift 5.1.22 + CometChatSDK 4.1.7 (symbols verified vs catalogs/ios-v5.json); signatures FETCHED via cometchat-ios-core/references/docs-map.md. The iOS UI Kit docs have no dedicated testing page — this is the pack's own guidance (tracked DOCS GAP). The kit ships prebuilt view controllers/SwiftUI views; do not assert against their internal view hierarchy.

Companion skills (read first)

• cometchat-ios-core — the init→login→render lifecycle and the credential flow these tests exercise.

Use this skill when

Adding tests around a CometChat iOS integration, or a "how do I test this" question. NOT part of a normal build — only when tests are explicitly requested (RULES.md → Verification scope).

Decide what you are testing

Test your code, not the kit. Three layers:

• Your logic (token fetch, UID mapping, view-model state, routing) → XCTest in isolation, keep the SDK off the network.
• Your wiring (the chat screen appears after init+login; the right IDs are passed) → a host-app test that drives the launch hook.
• The real round-trip (send → receive) → a thin XCUITest against a test app, not a unit test.

Do not unit-test that the kit's message list renders — that is the kit's own surface.

Keep the SDK off the network in unit tests

Put your CometChat calls behind a protocol your view-models depend on, and inject a fake in tests:

protocol ChatAuthing { func login(authToken: String) async throws -> String }   // returns uid
final class FakeChatAuth: ChatAuthing { func login(authToken: String) async throws -> String { "u1" } }

Test your token-fetch, error handling, and UID mapping against FakeChatAuth — no real CometChatUIKit.login, no network, no Auth Key in the test target. Injecting the real implementation only in the app keeps unit tests fast and hermetic.

The init→login gate in host-app tests

The chat screen mounts only after initFromSettings + login resolve (both async). A test that asserts immediately after presenting the screen races the gate — wait for a stable, YOUR-owned element (a title, an accessibility identifier you set), with an expectation/timeout, not a fixed sleep:

let list = app.otherElements["conversationsScreen"]   // an identifier YOU set on your container
XCTAssertTrue(list.waitForExistence(timeout: 20))

Set accessibilityIdentifiers on your own containers so UI tests have stable anchors that survive kit updates.