ドラッグ＆ドロップで画像を行へ移動するティアリストは、UIテストの題材として扱いやすい一方、単純な並べ替えコンポーネントとして実装すると要件が抜けやすい。検索、行編集、ローカル保存、PNG出力まで含めると、編集対象と表示対象を分離して考える必要がある。
この記事は、公開画面から観測できる操作をもとにした設計・テストメモであり、内部実装や本番DOMを解析したものではない。セレクター、件数、保存方式は実装時に置き換える前提の例である。
要件を操作ではなく結果で書く
「ドラッグできる」ではなく、次のように期待結果を書く。
| 操作 | 期待結果 | 境界条件 |
|---|---|---|
| 未配置アイテムをS行へ移動 | 所属が未配置からSへ変わる | 空行でも移動できる |
| 検索語を入力 | 表示候補だけが絞られる | 既配置アイテムの所属は不変 |
| 行名を変更 | 表示名だけが変わる | アイテム順序を壊さない |
| 行を追加 | 新しい行が編集・保存・出力対象になる | 初期行と同じ操作が可能 |
| PNG出力 | タイトル・行名・配置が画像に反映される | 検索中でも全体を出力する |
状態を分けて持つ
最低限、次の三種類を分けるとテストケースが読みやすくなる。
- ドキュメント状態：タイトル、行、アイテムの所属と順序
- 表示状態：検索語、選択中アイテム、プレビューの開閉
- 履歴・保存状態：Undo対象、ブラウザー内の保存データ、出力待ち
検索はドキュメント状態ではない。検索結果から見えなくなったキャラクターが、勝手に未配置へ戻る仕様なら、ユーザーは順位を失ったと感じる。逆にリセットは、どの状態を消すのかを明示しなければならない。
ドメインデータの準備
一般的な Tier List Maker では、画像を追加し、ティアへ配置し、ラベルを変えて、ランキング画像を出力する。対象がゲームキャラクターでも商品でも、テストの中心は「アイテムIDがコンテナ間を移動する」ことにある。
原神のように名前付き画像が多い題材では、Genshin Tier List Maker の122枚のスターター画像を、検索・大量データ・未配置一覧の検証に使える。ただし、ここで確認できるのは公開UIの操作契約であって、内部の保存方式やアクセシビリティ対応を保証するものではない。
E2Eの最小例
以下はPlaywrightの記法例であり、実際のセレクターや文言は対象アプリに合わせて確認する。
test("search does not change an existing placement", async ({ page }) => {
await page.goto("/ranking");
// Illustrative selectors: verify them against the real DOM.
await page.getByRole("button", { name: /Xingqiu/i }).click();
await page.getByRole("button", { name: "S" }).click();
await page.getByRole("searchbox").fill("Xingqiu");
await expect(page.getByText("Xingqiu")).toBeVisible();
await expect(page.locator('[data-tier="S"]')).toContainText("Xingqiu");
});
このテストの意図は、検索機能そのものよりも「表示状態の変更が編集状態を壊さない」ことを確認する点にある。
QAチェックリスト
- ポインター、タッチ、キーボードの各経路で移動できるか
- 空の行とアイテムが多い行で表示が崩れないか
- 行名の長さ、重複名、追加行を保存できるか
- リロード後にタイトルと配置が残るか
- 検索中の出力が全アイテムを含むか
- 画像追加・削除・Undoの順序が予想どおりか
- PNGの文字と色がプレビューと一致するか
まとめ
ティアリストUIの品質は、ドラッグの成功率だけでは決まらない。編集状態、表示状態、保存・出力状態の境界を要件として書き、状態遷移ごとにテストすれば、ゲーム以外のランキング画面にも同じ観点を適用できる。