cometchat-flutter-v6-testing

Ground truth: kit symbols are catalog-verified against 6.1.0. Test tooling (flutter_test, integration_test, mocktail) is standard Flutter, not CometChat API.

Companion skills (read first)

• cometchat-flutter-v6-core — install, credentials, init→login→render. This skill ASSUMES it.
• cometchat-flutter-v6-patterns — how init/login is gated, which is what your tests have to work around.

Use this skill when

The user ASKS for tests. Building a feature does not imply writing tests (RULES.md) — do not volunteer a test suite as part of "add chat".

Prerequisites & install

flutter pub add --dev mocktail integration_test

flutter_test ships with Flutter.

Test the RIGHT boundary (the thing most people get wrong)

Do not test the UI Kit. CometChatConversations rendering a list, CometChatMessageList appending a message, receipts, typing — all CometChat's own tested surface. Asserting on the kit's internals produces slow tests that break on every kit upgrade and prove nothing about YOUR app.

Test what is yours:

Worth testing	Why
The init/login gate	Your logic. Does a chat route stay unreachable until login resolves?
Navigation wiring	onItemTap pushes the right screen with the right user/group.
Target plumbing	The thread screen receives parentMessageId and the same user/group — the silent-never-sends trap.
Config selection	Prod flavour has no Auth Key; the right App ID per flavour.
Your own slots	Custom listItemView / subtitleView widgets render as expected.
Error paths	onError surfaces something to the user instead of a blank screen.

Widget tests — the practical constraint

A CometChat widget expects an initialized, logged-in SDK. In a unit/widget test there is none, so:

• Test your screens' STRUCTURE and wiring, not the kit's rendered output. Pump your screen and assert your own widgets, callbacks, and navigation.
• Keep chat screens behind a thin seam you can substitute — a factory/builder your test can swap for a stub. This is the single change that makes a CometChat app testable.
• Do not try to "mock the UI Kit widgets" — they are concrete widgets, not injectable interfaces. Swap at YOUR seam instead.

// A seam: your screen depends on a builder, so tests substitute a stub for the kit widget.
import 'package:cometchat_chat_uikit/cometchat_chat_uikit.dart';
import 'package:flutter/material.dart';

typedef ConversationsBuilder = Widget Function(void Function(Conversation) onTap);

class ChatsScreen extends StatelessWidget {
  final ConversationsBuilder builder;
  final void Function(Conversation) onOpen;
  const ChatsScreen({super.key, required this.builder, required this.onOpen});

  @override
  Widget build(BuildContext context) => Scaffold(body: SafeArea(child: builder(onOpen)));
}

// production wiring
Widget realConversations(void Function(Conversation) onTap) =>
    CometChatConversations(onItemTap: onTap);

In the test, pass a builder returning a plain ListView and assert that tapping a row calls onOpen with the right conversation — that is YOUR logic, tested fast and without a network.

Integration tests (integration_test)

The only place a real end-to-end chat flow can be asserted, because it needs a real init/login.

• Use a dedicated test CometChat app and seeded users (cometchat-uid-1…), never production data.
• Credentials come from the test flavour's settings asset, generated in CI — do not commit them.
• Keep the suite small: sign in → open a conversation → send a message → assert it appears. Broad E2E over the kit's own surface is slow and re-tests CometChat.
• Some things cannot be automated here and should be stated rather than faked: push delivery and real calls need physical devices.

CI

Run flutter analyze + unit/widget tests on every PR — they need no credentials. Gate integration tests behind a job that has the test-app secrets, and let them be non-blocking if the environment is flaky; a red build from a missing fixture teaches people to ignore CI.

Common pitfalls (BAKED)

• Writing tests nobody asked for (RULES.md).
• Testing the UI Kit instead of your wiring.
• Trying to mock kit widgets directly — introduce a seam instead.
• Widget-testing a screen that calls init/login → hangs or throws; gate it behind the seam.
• Integration tests against production — use a test app.
• Committing test credentials.
• Claiming push/calls are covered when they need real devices.

Verify it works

Unit/widget tests run with no network and no credentials; integration tests pass against the test app; flutter analyze is clean; nothing in the suite asserts on CometChat's internal rendering.