Developer / 開発ツール（API 2026-04）

UI 拡張の「自動テスト」が公式化
@shopify/ui-extensions-tester

Checkout / Admin / Customer Accounts / POS のどのサーフェスの UI 拡張でも、Shopify の実行ホストを起動せずにユニットテストが書ける公式テストライブラリ。実 API と同じ型の安全なモックで、隔離レンダリング・操作シミュレート・検証ができる。

このページの構成
  1. そもそも何ができるのか（30秒で理解）
  2. 仕組み図解 ： テストが走る流れ
  3. 5 つの主要機能（Key capabilities）
  4. 対応する 4 つのサーフェス
  5. 従来 vs テスター の比較
  6. 始め方（Getting started）
  7. 技術者が押さえるべき 5 つのポイント
  8. 業務に活かせる 3 つのユースケース
  9. 提案で使える 1 行サマリ

1そもそも何ができるのか

API version 2026-04 から、Shopify が UI 拡張用の公式テストライブラリを提供。
@shopify/ui-extensions-tester を使うと、Shopify の実行ホストを起動せずに、 どのサーフェスの拡張でもユニットテストが書ける。

従来 ： 実行ホストが前提

拡張の動作確認には、稼働中の Shopify ホスト（実機環境）が必要だった。隔離した状態でロジックだけを素早く検証する公式手段が無かった。

これから ： ホスト不要で単体テスト

拡張 API の型付きモックを使い、拡張を隔離レンダリング → 操作をシミュレート → 公開 API に対して挙動を検証。すべて型安全に行える。

提供される型付きモックは実際の拡張 API と同じ型を使う。これにより、誤った API の使い方をテスト時点で捕まえられる（実行して初めて気づく、ではない）。

2仕組み図解 ： テストが走る流れ

拡張コード UI Extension テスト対象 DOM にレンダリング 標準 DOM 環境で隔離 ＋ 出力を query render & query mocked shopify 実 API と同じ型 サーフェス別の既定値 type-safe mocks 操作シミュレート → 検証 dispatchEvent() で操作を発火 @testing-library/preact で非同期 公開 API に対して assert ✓
ポイントは「Shopify ホストが流れの中に一切出てこない」こと。レンダリングもモックも操作もすべてローカルの標準 DOM 環境で完結するため、CI に組み込みやすい。

35 つの主要機能（Key capabilities）

① Render & query

拡張を標準的な DOM 環境にレンダリングし、出力を標準のテストパターンで query（検索・取得）できる。

type

② 型安全なモック

モックされた shopify グローバルは実 API と同じ型を使用。誤った API 使用をテスト時に検出する。

③ サーフェス別の既定値

Checkout / Admin / Customer Accounts / POS それぞれに妥当なモック既定値が用意され、テストが「すぐ動く」。

④ イベントシミュレーション

ユーザー操作を発火し、非同期の状態変化を dispatchEvent() または @testing-library/preact でテストできる。

⑤ AI エージェント・フレンドリー

強い型付きのモックと予測可能なテストパターンにより、AI 支援のテスト駆動開発（TDD）に適している、と記事が明示している。

4対応する 4 つのサーフェス

いずれのサーフェスの拡張でも、稼働中の Shopify ホスト無しでテストできる。

Checkout UI
チェックアウト拡張
Admin
管理画面拡張
Customer Accounts
顧客アカウント拡張
POS
POS 拡張

5従来 vs テスター の比較

項目従来@shopify/ui-extensions-tester
実行環境 ホスト必要 稼働中の Shopify ホストが前提 ホスト不要 標準 DOM 環境で完結
API のモック 公式の型付きモックは無し 公式提供 実 API と同じ型のモック
サーフェス対応 — Checkout / Admin / Customer Accounts / POS に既定値
ユーザー操作の再現 実環境での手動操作が中心 dispatchEvent()・@testing-library/preact でシミュレート
API 誤用の検出 実行して初めて顕在化しがち テスト時 型でテスト時点に検出
「従来」列は、本記事が示す「公式ライブラリの登場」「ホスト不要」という記述からの対比。従来手段の具体仕様は本記事には記載なし。

6始め方（Getting started）

1

ドキュメントを読む

公式ドキュメントで詳細を把握する。

2

サンプルから始める

サーフェスごとのサンプルテストスイートを土台に着手。

3

レンダー → 操作 → 検証

拡張を描画し、操作をシミュレートして公開 API に対し検証。

具体的なインストールコマンドや導入手順は本記事に記載なし。サーフェス別のサンプルテストスイートと公式ドキュメントを参照すること。

7技術者が押さえるべき 5 つのポイント

2026 -04

1. 提供は API 2026-04 から

この公式テストライブラリは API version 2026-04 以降で提供される。利用前提として拡張のバージョン整合を確認する。

2. ホスト不要 ＝ CI と相性◎

稼働中の Shopify ホスト無しで完結するユニットテストなので、PR ごとの CI 実行や自動回帰テストに組み込みやすい。

type ✓

3. 型でテスト時に誤用検出

モックされた shopify グローバルが実 API と同じ型のため、API の誤った使い方がテスト時点で型エラーとして顕在化する。

4. 非同期状態のテスト手段

ユーザー操作の発火と非同期な状態変化の検証は dispatchEvent() もしくは @testing-library/preact で行う。

5. AI 駆動 TDD に最適化されている

強い型付きと予測可能なテストパターンにより、AI 支援のテスト駆動開発に向くと明記されている。AI 生成コードの検証ハーネスとして使うと、誤った API 使用が型で弾かれるため手戻りを抑えられる。

8業務に活かせる 3 つのユースケース

USE CASE 1

Checkout 拡張のリグレッションを CI で止める

課題
作り込んだ Checkout UI 拡張が、API バージョン更新やリファクタで壊れても、実機プレビューでしか気づけずデグレが本番へ流出しやすい。
打ち手
拡張を標準 DOM 環境にレンダリングし、表示・分岐ロジックをユニットテスト化。PR ごとに CI で実行する。
効果
ホスト起動不要で高速にリグレッションを検知。本番デグレを未然に防ぐ。
技術メモ
型安全モックで API 誤用を型エラー化。dispatchEvent() で非同期な状態遷移も検証できる。
USE CASE 2

AI 支援のテスト駆動開発で開発速度を上げる

課題
拡張のテストは環境構築が重く、AI にコードを書かせても確かな検証手段がなく品質を担保しにくい。
打ち手
記事が示す「AI エージェント・フレンドリー」な強い型と予測可能なテストパターンを活かし、AI にテスト→実装の TDD サイクルを回させる。
効果
AI 生成コードを自動テストで即検証し手戻りを削減。テストが仕様の役割も果たし引き継ぎが楽になる。
技術メモ
モックされた shopify グローバルが実 API と同型のため、AI が誤用してもテスト時点で検出される。
USE CASE 3

マルチサーフェス拡張の品質を一括で担保する

課題
同一機能を Admin・POS・Customer Accounts など複数サーフェスへ展開する案件で、サーフェスごとの動作確認の手間が膨らむ。
打ち手
サーフェス別の妥当な既定値を使い、各ターゲット向けテストを「設定なしで動く」状態から書き始め、横断的にテストスイートを整備する。
効果
各サーフェスの回帰テストを統一的に自動化し、受託開発の納品品質を平準化できる。
技術メモ
surface-specific defaults により Checkout / Admin / Customer Accounts / POS それぞれのモック初期値が用意されている。

9提案で使える 1 行サマリ

「API 2026-04 から使える Shopify 公式の UI 拡張テストライブラリ。
Shopify ホスト不要・実 API と同型の型安全モック・全 4 サーフェス対応で、
CI に組み込めるユニットテストと AI 駆動 TDD が“設定なし”で始められる。」