Testing your work

There is no separate test harness for blocks and integrations. Your verification loop is the running app. What matters is exercising the states your code will actually meet in production: real config, missing config, and both platforms.

Run it where it will run

Test on both platforms before calling anything done. Layout, safe areas, keyboard behavior, and native modules all differ between iOS and Android, and a block that looks right on one can clip or crash on the other.

pnpm run-ios
pnpm run-android

Exercise every config state

Blocks are configured by people, from the dashboard, so your block will eventually render with config you did not anticipate. Walk it through:

• Full config — everything your schema documents, filled in.
• Partial config — optional fields missing.
• Empty or missing config — the block just placed, nothing filled in yet.

A block must fail soft: when required config is missing, return null (optionally with a console.warn) rather than crashing the screen. A thrown render error takes the whole screen down with it.

const source = useBlockSettings(block) as PromoBannerConfig
if (!source?.title) {
  console.warn(`[promo-banner] missing required config`)
  return null
}

Test against a draft theme

Make config changes on a draft theme, never the live one — the live theme is what real shoppers see. Place your block on a draft, iterate on its source/style/options there, and only hand off once it behaves across the states above. Config and theme explains the draft model.

Verify trackers end to end

For analytics trackers, local behavior is not proof. The events must arrive on your platform:

1. Run the app with your integration's settings configured.
2. Exercise the flows behind your event whitelist: view a product, add to cart, purchase.
3. Confirm each event arrives once, under the mapped name, with the payload you expect, in your platform's live-events or debugger view.

Remember: an unset whitelist means no events are forwarded at all. If nothing arrives, check the whitelist before anything else. Analytics trackers covers the details.

Pre-handoff checklist

Before you publish a package or hand work back to Appbrew:

• Works on iOS and Android.
• Handles full, partial, and empty config without crashing.
• No new console errors or warnings in a normal session.
• Every merchant-facing setting your manifest declares is documented, with what happens when it is unset.
• For trackers: events verified end to end on your platform.
• README updated: what the package does, its settings, its metafield requirements if any.

When all boxes tick, you are ready to publish your package or request a release.