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
bashflutter 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.
dart// 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}); 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.

