DEV Community: qinjie xu

AddressLab: A Reproducible Workflow for Generating Valid Test Address Data

qinjie xu — Thu, 01 Oct 2026 00:42:41 +0000

The Problem with Synthetic Address Data in CI Pipelines

Every developer who builds location-aware features eventually hits the same wall: realistic address data for testing. Hardcoding a few US addresses works until your test matrix expands. You need tax-free states for e-commerce checkout flows, international formats for localization, and enough volume to stress pagination or geocoding APIs. Generating this manually wastes time; pulling from production risks PII exposure. The gap between "I need data" and "I have clean, safe test data" is where most workflows stall.

This matters because modern AI and automation pipelines demand structured, varied inputs. Whether you're training a model on address parsing, testing a shipping calculator, or validating form field extraction, your test data needs to be reproducible, configurable, and exportable in formats your toolchain already consumes.

What AddressLab Provides

AddressLab is a free, no-sign-up US address generator that outputs structured location data without registration friction. It covers tax-free states (useful for sales-tax logic testing), includes multi-country address samples, and adds random email-format fields so you can test contact flows alongside physical addresses. Outputs save locally, with CSV or JSON export for direct pipeline injection.

For developers building AI workflow automation—turning scattered tasks into repeatable pipelines—this eliminates a common preprocessing bottleneck. No API keys to manage, no rate limits to negotiate, no PII to sanitize.

Setting Up the Reproducible Workflow

Step 1: Define Your Test Matrix

Before generating data, document what you actually need. A minimal matrix for a typical e-commerce or logistics pipeline:

Dimension	Values to Cover
Country	US (primary), CA, GB, DE, AU (secondary)
US State Type	Tax-free (AK, DE, MT, NH, OR), taxable, territory
Address Completeness	Full, missing apartment, PO box, rural route
Email Association	Present, absent, malformed (for negative testing)
Output Format	JSON (API testing), CSV (spreadsheet/ML ingestion)

Step 2: Generate and Capture from AddressLab

Navigate to AddressLab and configure your parameters. The interface presents:

Country selector: US default, with additional countries as samples
State filter: Include/exclude tax-free states
Email toggle: Append random email-format string to each record
Count control: Batch size for generation
Export format: JSON array or CSV with headers

Generate your first batch. For a 500-record US-only set with tax-free state coverage and email fields:

# Typical JSON export structure from AddressLab
[
  {
    "name": "...",
    "street": "123 Main St",
    "city": "Portland",
    "state": "OR",
    "zip": "97201",
    "country": "US",
    "email": "user_7a3f@example.com"
  },
  ...
]

Save the file to your project's test/fixtures/ directory with a versioned filename: addresses_v20241001_500.json.

Step 3: Integrate into Your CI Pipeline

Load the fixture directly or wrap it in a helper. Example for a Node.js test suite:

// test/helpers/addressLoader.js
const fs = require('fs');
const path = require('path');

const loadAddresses = (variant = 'default') => {
  const filePath = path.join(
    __dirname,
    '../fixtures',
    `addresses_${variant}.json`
  );
  return JSON.parse(fs.readFileSync(filePath, 'utf8'));
};

module.exports = { loadAddresses };

In your test:

const { loadAddresses } = require('./helpers/addressLoader');

describe('shipping calculator', () => {
  const addresses = loadAddresses('v20241001_500');

  test.each(addresses.filter(a => a.state === 'OR'))(
    'calculates zero tax for $state address',
    (address) => {
      expect(calculateTax(address)).toBe(0);
    }
  );
});

Step 4: Maintain Reproducibility with Version Pinning

The risk with any external data source is drift. AddressLab's local-save model helps here: once exported, your fixture is immutable. Document the generation parameters in a FIXTURES.md:

## Address Fixtures

| File | Source | Date | Count | Parameters |
|------|--------|------|-------|------------|
| addresses_v20241001_500.json | AddressLab | 2024-10-01 | 500 | US only, tax-free included, email enabled |
| addresses_v20241001_100_intl.json | AddressLab | 2024-10-01 | 100 | Multi-country, no email |

When your test matrix expands, generate a new fixture rather than mutating existing ones. This preserves historical test behavior and enables bisection if regressions appear.

Validation and Debug Checks

Before relying on generated data, verify these properties:

Structural integrity: Confirm every record has required fields. For US addresses: street, city, state, ZIP, country. Missing fields should fail your loader explicitly, not propagate as undefined.

State coverage: If your logic branches on tax-free states, assert your fixture contains at least one example from each. A coverage gap here silently invalidates tax tests.

ZIP format validity: US ZIPs should match ^\d{5}(-\d{4})?$. AddressLab generates realistic formats, but your pipeline should validate before passing to downstream services.

Email field behavior: When enabled, the email string follows local@domain pattern but resolves to non-deliverable addresses by design. Confirm your system doesn't accidentally send to them during integration tests.

International format variance: Non-US addresses from the multi-country sample use local conventions (postal codes, province names, address ordering). Verify your parser handles these without US-centric assumptions.

Run a smoke check on each new fixture:

# Example validation script
node -e "
const data = require('./test/fixtures/addresses_v20241001_500.json');
const states = new Set(data.map(d => d.state));
const required = ['OR', 'DE', 'AK', 'MT', 'NH']; // tax-free baseline
const missing = required.filter(s => !states.has(s));
if (missing.length) throw new Error('Missing states: ' + missing);
console.log('Fixture valid:', data.length, 'records,', states.size, 'unique states');
"

Extending the Workflow

For teams running larger test suites or ML training pipelines, consider these extensions:

Parameterize fixture selection: Use environment variables to switch between small (fast unit tests) and large (integration/performance tests) fixtures without code changes.
Generate diffs on schema changes: If AddressLab updates its export format, compare against your pinned fixtures to catch breaking changes before they reach CI.
Combine with property-based testing: Use AddressLab for seed data, then apply tools like fast-check or Hypothesis to mutate fields and test edge cases.

Takeaway

Reliable test data is infrastructure, not an afterthought. AddressLab removes the friction of generating structured address fixtures while keeping your data local, versionable, and pipeline-ready. If your team needs repeatable location data for CI, the workflow above gives you a concrete starting point without external dependencies or compliance overhead.

For the current interface and export options, see AddressLab.

Using ChatMock to Generate Reproducible Chat UI Fixtures for UI Testing and Prototyping

qinjie xu — Mon, 14 Sep 2026 13:19:14 +0000

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 role assignments.

Timestamp consistency check

Timestamps in the mockup should be monotonically increasing and match the time values 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	WhatsApp	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.