cometchat-flutter-v6-testing

v2026.09.25

Test a Flutter app that uses the CometChat UI Kit — what is worth testing versus what belongs to the kit, mocking the SDK boundary, widget tests around chat screens, and integration/CI setup. Triggers: 'test my cometchat integration', 'mock cometchat in flutter tests', 'widget test chat screen', 'cometchat test setup'.

GitHub
Install command
npx skhub add cometchat/cometchat-flutter-v6-testing
Markdown
SKILL.md

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 testingWhy
The init/login gateYour logic. Does a chat route stay unreachable until login resolves?
Navigation wiringonItemTap pushes the right screen with the right user/group.
Target plumbingThe thread screen receives parentMessageId and the same user/group — the silent-never-sends trap.
Config selectionProd flavour has no Auth Key; the right App ID per flavour.
Your own slotsCustom listItemView / subtitleView widgets render as expected.
Error pathsonError 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.

Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.25

Published

Sep 25, 2026

Category

Uncategorized

License

MIT

Source path

skills/cometchat-flutter-v6-testing

Default branch

main

Latest commit

f92ff9e

Tree SHA

f40470f