break

Break

このスキルでは、1つのコンポーネントを受け取り、実際に到達し得るあらゆるシナリオでハーネスページに表示します。そのページが成果物です。ユーザーがスクロールして確認するビジュアルレポートで、すべてのシナリオが並んで表示され、問題箇所が示されます。

評価するのではなく、観察します。ここでの指摘とは、ページ上で目に見える形で発生した問題を、修正を担当するドメインスキルの用語で示したものです。標準に照らしてコードをレビューするなら interface-review と better-interface、デザインの代替案を探るなら variant、コンポーネントのプロダクト状態を1つずつ確認するなら state-machine を使います。

variant が実際のページでの確認にこだわるのに対し、このスキルでは意図的に切り離して確認します。コンポーネントが周囲の文脈でどう見えるかを評価するのではありません。コンテンツが最悪の状態でも、コンポーネントがそれに対応できるかを確認します。

実行の流れは、ビルドして、一度見て、報告するだけです。セッションではなく、数分で終わります。計測機能の追加、ブラウザーのデバッグ、二度目の確認は、いずれも必要ありません。

1. コンポーネントを1つに絞る

1回の実行につき、コンポーネントは1つです。「設定ページ」はコンポーネントではありませんが、プロフィールフォームのテキスト入力欄はコンポーネントです。依頼の対象が複数にわたる場合は候補を列挙し、どれをテストするか尋ねます。

コンポーネントが何かを1文で言い直します。何を受け取り、何を描画し、どこで使われるのかを示します。

2. コンポーネントからシナリオを推測する

変化するものだけをストレステストします。本番環境でその形を取り得る値をコンポーネントが受け取る場合、そのシナリオを対象に加えます。まずコンポーネントを読み、props、スロット、状態、描画するデータを確認します。

scenarios.md には、軸、それぞれの値、軸を適用するかどうかを判断する手掛かりが記載されています。コンポーネントと照らし合わせ、手掛かりが一致する軸だけを残します。テキスト入力欄にはコンテンツの長さと状態を適用しますが、項目数は適用しません。ラベルが固定された静的なアイコンボタンには、コンテナと環境を適用しますが、長いテキストは適用しません。

構築を始める前に、残したシナリオをそれぞれ1行で書き出します。次に、除外した軸とその理由を1行で示します。推測が間違っていても、すぐに見つけられるようにするためです。

3. ハーネスページを構築する

ハーネスページでは、各シナリオのコンポーネントを1列に1つずつ表示し、それぞれの上に短いテキストラベルを付けます。

アプリ内のスクラッチ用ルートに、プロジェクトからインポートした実際のコンポーネントを変更せずに配置します。ルートはアプリのレイアウト、フォント、グローバルスタイル、プロバイダーをそのまま利用できます。

フレームワークでサーバーコンポーネントとクライアントコンポーネントを分ける場合、ページはクライアントコードにします。Next では "use client" を指定します。そうしないと、フィクスチャデータが境界を越える際にひそかに失われ、ページが空で表示されることがあります。

ページに追加するのは、ラベル、コンテナの幅、フィクスチャの props だけです。ページ独自のフォントやスタイル、テーマのシミュレーションやトークンの差し替え、プローブは加えません。これらのいずれかを適用した状態で観察したコンポーネントは、別のコンポーネントです。

シナリオは props とフィクスチャデータとして渡します。ハーネスが本番の状態をインポートすることも、実データに接続することもありません。また、本番コードがハーネスから何かをインポートすることもありません。

4. 一度だけ確認する

すでに使えるブラウザーでページを一度読み込み、上から下まで各シナリオをざっと確認し、目に見えて発生した問題を書き留めます。「テキストがフィールドの右端からはみ出している」と記録し、「間隔が窮屈に感じる」とは書きません。予測しただけの問題は指摘に含めません。

すぐ使えるブラウザーがない場合は、その旨を伝え、ユーザーに確認してもらうために URL を共有します。ブラウザーの起動、ウィンドウの操作、デバッグは、いずれも作業範囲外です。確認を省略した場合、レポートは URL とシナリオ一覧のみとし、指摘一覧表やページ上の注記は含めません。

実際に確認した問題は、それぞれ該当するシナリオのラベルの下に1行の注記としてページに記し、1回の編集でまとめて反映します。ページだけでレポートとして読める必要があります。

5. 崩れた箇所を報告して終了します

崩れたシナリオを先にして、調査結果を表で報告します。

シナリオ	確認された状態	担当
改行できない60文字の文字列が1つある	カードからはみ出し、折り返しも省略もされない	better-typography
項目が0件	メッセージのない空白領域が表示される	better-writing

このスキルはドメインルールを持たず、判定も行いません。

「すべて問題ありませんでした」は、完全で有用な報告です。ページにあるシナリオと実行環境を示せば、ユーザー自身ですべて確認できます。好みで内容を膨らませず、そこで終わります。

依頼されていないことは修正しません。修正を依頼された場合は、担当スキルのルールに従い、失敗したシナリオを再度レンダリングして確認します。

6. ページは表示したままにし、依頼されたら削除します

ページは報告の半分を占めるため、調査結果の表より長く残します。起動したままにしてください。ユーザーから終了の連絡があった場合にのみ、ページとそのフィクスチャを削除します。その後、ルートとフィクスチャ名を検索し、ハーネスの痕跡が差分に残っていないことを確認します。

終了する前に

間違い	対処
すべての軸をすべてのコンポーネントで実行する	手掛かりが一致する軸だけを残し、除外した軸を明記します
予測した失敗を確認済みとして報告する	レンダリングするか、報告から除外します
入力したコンテンツがシナリオに反映されていない	ハーネスの不具合です。コンポーネントのクライアントコードをページに追加し、1回再読み込みします
ハーネス内で見た目だけ似せたコンポーネントを再構築する	プロジェクトから実際のコンポーネントをインポートします
ハーネスがコンポーネントのスタイルやテーマを変更する	アプリのレイアウト、フォント、トークンをそのまま使用します。ページに追加するのはラベルと幅だけです
シナリオごとにブラウザーを起動、デバッグ、またはスクリーンショット撮影する	1回読み込んで1回確認するか、URLを渡して確認を省略します
見た目の好みとして調査結果を述べる	ページで確認できた内容を報告するか、何も報告しません
崩れを担当者なしで報告する	原因を診断するルールを持つドメインスキルを明記します
問題がなかった実行結果に提案を付け足す	シナリオ一覧と「すべて問題ありませんでした」が報告です
シナリオごとにビューポートを変更する	ページ上の固定コンテナーで幅を設定します。1回読み込めばすべて確認できます
表には崩れがあるのに、ページ上では明示されていない	シナリオのラベルの下に注記します。ページだけで報告として読めるようにします
報告と同じターンでページを削除する	ページは報告の半分を占めます。ユーザーから指示があった場合にのみ削除します