Skip to content

テストファイル作成の手順

Jump to bottom Edit New page
atsushi akiyama edited this page Dec 14, 2022 · 27 revisions

手順1. [個人] 「達成方法」の「事例」をベースに、テストファイルが作成可能か確認する

実施事項

  1. 達成方法の事例が UA のテスト となっているかの確認
  2. 達成方法の事例に掲載コードの妥当性確認
  3. 達成方法の事例に掲載されているコードの整形

流れ

  1. 「事例」が UA のテスト となっているかの確認
    • 「事例」記載内容で想定されるケース
      • UA のテストとなっている
        • 例 : xxxxx
      • コンテンツのテストとなっている
        • 例 : xxxxx
    • 対応方法
      • UAのテストとなっている場合
        • テストを詰める。
      • コンテンツのテストとなっている場合
        • 1次案作成のタイミング（後述）にて、UA のテストとなるように修正する。
  2. 事例に掲載コードの妥当性確認
    • 事例に掲載されているコードに、廃止要素や廃止属性、推奨されない属性が利用されていないかどうかを確認する。
    • 例 : table 要素にて summary 属性を利用している。
  3. 事例に掲載されているコードの整形
    • 事例に掲載されているコードが、WAIC のコードフォーマットに則っているかどうかを確認する。
      • 「WAIC の」 としたが、明確にはコードフォーマットは存在しない（はず）
    • 例 : 空要素は、< /> ではなく < > として記述する。
      • 基本は html 構文として記載する。
      • なんらか xml 構文である必要がある場合は、対象の構文を保持する。

手順2. [個人] テストケースとテストコードを作成する

実施事項

  1. テストケース/コードのファイル名称を決定。
  2. git issue を立てる。

流れ

  1. テストケース/コードのファイル名称を決定
    • ファイル名規則
      • テストケース : WAIC-TEST-XXXX-YY.md
      • テストコード : WAIC-CODE-XXXX-YY.html
    • 新規でテストケースを作成する場合は、直前のテストからの連番で良い。
    • 既存のテストファイルは、廃番などにより必ずしも連番にはなっていない。
  2. git issue を立てる
    • テストケースのファイル名称 + テストタイトル
    • テストタイトルは、内容を端的に示したものとする。
      • 検討が重い場合は、安直なタイトルでも良い。（タイトルは後でも修正可能。必要であれば、レビュー時にタイトルを修正する。）
      • テストタイトルは一意なものとする（テストタイトルの重複を避ける）

手順3. [個人] テストファイル1次案の作成

実施事項

  1. テストタイトル
  2. テストの目的
  3. テストの対象となる達成基準 (複数)
  4. 関連する達成方法 (複数)
  5. テストコード
  6. 関連する要素や属性
  7. どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
  8. PR を作成する

流れ

  1. テストタイトル
    • 考慮すべき点
      • Techniques の「解説」を確認し、テスト内容を端的に示したものとする。
      • テストタイトルは一意なものとする（テストタイトルの重複を避ける）
    • 参考 : テストの一覧
    • 例 (WAIC-TEST-0029-03) : aria-describedby 属性による説明ラベルの提供 (button要素)
      • テストする属性名とともに、その属性が何に用いられているかを示す。
      • 末尾に属性を指定する要素や属性値を含め、類似するテストとの違いを示す。
    • テストタイトルは、後述の「テストの目的」の後に作成した方が、妥当性を判断しやすい。
  2. テストの目的
    • Techniques の「解説」を確認し、何のテストを行うかを記す。
  3. テストの対象となる達成基準 (複数)
    • Techniques の「適用（対象）」を確認し、その内容を列記する。
  4. 関連する達成方法 (複数)
    • 参照している Techniques の達成方法番号を記載する
  5. テストコード
    • Techniques の事例のコードより転載。
    • 画像などのリソースが確認できない場合は、適当な代用リソースを準備。
    • 利用できないと判断される場合
      • UA のテストとなっている
      • コンテンツのテストとなっている
  6. 関連する要素や属性
    • テストコードを確認し、利用している要素を抽出。
    • cssのプロパティなどは記載しない。HTMLの要素と属性のみに言及する。
  7. どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
    • 議論で一番神経を使うところ。
      • 一人でここを決めるのは非常に難しい箇所となるため、まずは議論のきっかけとなるようにライトに記載。
      • 記載が難しい場合、「何を記載すればよいか？」を議論するために、他の項目を埋めるようにする。
    • 考慮すべき点
  8. PR を作成する
    • テストファイル、テストコードを準備し、PR を作成する。
      • PR では、該当の issue と紐づけを行う。

手順4. [チーム] チームレビュー

  • 「作る」チームの中でレビューを行う
    • チームレビューでは、作成したテストファイルの記載漏れ、テストコードの不備などがないかを確認。
      • 特に、テストの目的がしっかりと記載されているかを確認する。
    • どんなテストをすれば良いかの議論までできれば理想だが、難しければ全体レビューへと回す。
  • 全体レビューへの申し送り事項がある場合、明確にしておく。（issue に記載する）

手順5. [個人] 2次案作成

  • チームレビューを踏まえて、修正を行う。
  • 不要な場合は次のステップに進む。

手順6. [チーム] 全体レビュー

  • WG2 全体でレビューを行う。
  • （レビュー期間を1週間とし、担当者以外のWG2委員最低2名以上がレビューするものとする。意見が出た場合は2次案作成にもどって修正・チームレビューを再度行う。）

手順7. [チーム] 完成

  • issue を閉じる。PR をマージする。

その他

テストが不要となった場合

レビューの結果、テストそのものを行わないことが決定した場合、以下の作業を行う。

  • GitHub から当該テストファイル及びテストコードを削除。その際削除した理由をcommit message に残す。
  • 当該 issue にテストを行わない旨を記載して close
  • 進捗管理用ページ の該当する行を削除

削除されたテストのテスト番号は欠番とする。

テストファイル作成対象とする達成方法

  • G の項目については、テストをしない
Add a custom footer
Add a custom sidebar
Clone this wiki locally