The Problem: Chat UI Fixtures Are Hard to Keep Consistent
Anyone who has built a chat interface—whether for a support widget, an onboarding flow, or a messaging feature—knows the pain of maintaining realistic test fixtures. Screenshots taken from live apps are fragile: they carry real user data, vary by device, get stale, and usually require someone with access to a production environment to refresh them. Manually editing HTML or constructing JSON payloads for mocked conversations adds friction to every sprint cycle.
ChatMock is a browser-based tool that generates realistic chat mockups for WhatsApp, Messenger, Instagram DM, and similar interfaces. It runs entirely in the browser, requires no signup, and applies no watermark. For teams that need reproducible visual fixtures—for UI review, design handoff, or documentation—this is a meaningful constraint to evaluate: zero server-side upload means the fixture workflow stays local and auditable.
This article walks through a concrete workflow for integrating ChatMock into a UI fixture pipeline, including reproducibility considerations, a sample fixture spec, and quality checks you can apply before committing assets.
Technical Context: What "Browser-Only" Actually Means for Your Pipeline
When a tool advertises that everything renders in the browser, it has a specific implication for reproducibility: there is no shared server state, no API call that could return different results on a different day, and no account-level configuration that silently changes output.
For chat UI fixtures, this is useful in two scenarios:
- Snapshot testing baselines — You want a fixture that looks the same every time it is captured, so visual regression tools (Percy, Chromatic, BackstopJS) can diff against a stable baseline.
- Documentation and handoff — Design specs and README screenshots need to stay accurate without requiring a live environment.
The tradeoff is that browser-rendered tools are generally not scriptable via CLI. The fixture generation step is manual, which means you need a deterministic input spec so that any team member can reproduce the same output. The workflow below addresses that.
Setup: Defining a Reproducible Fixture Spec
Before opening the tool, define your fixture as a plain text or JSON spec. This becomes the source of truth that lives in your repository and can be reviewed in pull requests.
Example fixture spec file (fixtures/onboarding-chat.fixture.json):
{
"platform": "whatsapp",
"fixture_id": "onboarding-welcome-v2",
"participants": [
{ "handle": "Support Bot", "role": "agent", "avatar": "bot" },
{ "handle": "New User", "role": "user", "avatar": "person" }
],
"messages": [
{ "from": "agent", "text": "Welcome! How can I help you get started today?", "time": "10:01" },
{ "from": "user", "text": "I just signed up and I'm not sure where to begin.", "time": "10:02" },
{ "from": "agent", "text": "No problem. Let me walk you through the first three steps.", "time": "10:02" },
{ "from": "agent", "text": "Step 1: Connect your data source. Step 2: Configure your first workflow. Step 3: Run a test message.", "time": "10:03" },
{ "from": "user", "text": "Got it, thanks!", "time": "10:04" }
],
"export_format": "png",
"resolution": "2x",
"notes": "Used for onboarding docs and README header. Regenerate if copy changes."
}
This spec is human-readable, diffable in Git, and gives any team member the exact inputs needed to regenerate the fixture using ChatMock.
Workflow: Generating and Capturing the Fixture
With the spec committed, the generation steps are:
Step 1 — Load the platform template.
Open ChatMock, select the target platform (e.g., WhatsApp). The interface renders a phone-frame mockup with editable message fields.
Step 2 — Populate from the spec.
Enter the messages in sequence, matching the from, text, and time fields from the fixture spec. For multi-participant threads, assign the correct sender role to each bubble.
Step 3 — Verify visual state before capture.
Before exporting, run through the quality checklist in the next section. Common issues include mismatched timestamps, truncated long messages, and incorrect bubble alignment (sent vs. received).
Step 4 — Export and commit.
Export the rendered mockup (PNG at 2x if the tool supports it, or capture at device-pixel-ratio 2 using a browser screenshot extension). Save to fixtures/assets/onboarding-welcome-v2.png.
Step 5 — Update the spec notes field with the date and the reason for the regeneration, then commit both the spec and the asset together.
Example commit message convention:
fix(fixtures): regenerate onboarding-welcome-v2 for updated step copy
Spec: fixtures/onboarding-chat.fixture.json
Asset: fixtures/assets/onboarding-welcome-v2.png
Tool: ChatMock (browser-rendered, no upload)
This keeps the asset traceable to the spec without any external service dependency.
Quality Checks Before Committing a Fixture
For chat mockups to be useful as test fixtures or documentation assets, apply these checks before treating a render as final:
Bubble alignment check
- Sent messages (agent or bot) should appear on the correct side for the target platform. WhatsApp places sent messages on the right; verify this matches your fixture spec's
roleassignments.
Timestamp consistency check
- Timestamps in the mockup should be monotonically increasing and match the
timevalues in the spec. Mismatched times introduce confusion in documentation that describes a sequence.
Text truncation check
- If a message contains more than ~160 characters, verify it wraps correctly within the bubble and is not clipped. Capture the full message area in your screenshot.
Platform chrome accuracy
Compare the rendered header (contact name, status indicator, platform-specific icons) against a reference screenshot of the actual platform. For documentation purposes, the chrome should be close enough that readers recognize the interface at a glance.
Watermark / attribution check
ChatMock exports without a watermark, which is a stated feature. Verify the exported PNG contains no overlay text or logo before using it in production documentation or public-facing materials.
Reproducibility smoke test
Have a second team member follow the spec independently and compare the output. Pixel-perfect parity is not the goal; structural and copy parity is. If the two outputs differ in message order or copy, the spec is ambiguous and needs tightening.
A lightweight test matrix for tracking fixture status:
| Fixture ID | Platform | Last Generated | Spec Version | Alignment OK | Timestamps OK | Truncation OK |
|---|---|---|---|---|---|---|
| onboarding-welcome-v2 | 2026-09-14 | v2 | ✅ | ✅ | ✅ | |
| support-error-state-v1 | Messenger | 2026-08-30 | v1 | ✅ | ⚠️ | ✅ |
Track this matrix in a FIXTURES.md file alongside the spec JSON files.
Takeaway
Browser-only, no-signup tooling like ChatMock shifts the reproducibility problem from infrastructure to process. The tool itself has no state to drift; your fixture spec is the single source of truth. For teams that already use snapshot testing or maintain documentation screenshots, layering a structured spec file and a commit convention on top of the mockup generation step is a low-overhead way to keep visual fixtures reviewable and auditable.
If your team maintains chat UI fixtures manually or relies on screenshots from live environments, adopting a spec-driven approach reduces the surface area for inconsistency without requiring any new infrastructure. The workflow above is directly adoptable: copy the fixture spec schema, adapt the message content, and establish the commit convention as a contribution guideline.
Top comments (1)
A frozen input spec is the key here. I’d version the message set, viewport, locale, font stack, and capture timestamp policy together, then have CI render the fixture from that bundle. That makes a visual diff attributable to a product change rather than an accidental environment change.