理解度チェック：テスト設計の基本

ストーリー

「テスト設計の基本は理解できたか？ 確認テストだ」

松本先輩が問題を用意した。

「テストの種類、設計技法、TDD、カバレッジ。 基礎がしっかりしていないと実践で困るぞ」

クイズの説明

Step 3 で学んだテスト設計の基本知識を確認します。

• 全5問
• 合格ライン: 80%（4問正解）

問題

Q1. テストピラミッドにおいて、最も多く書くべきテストの種類はどれですか？

• A) E2Eテスト
• B) インテグレーションテスト
• C) ユニットテスト
• D) 手動テスト

正解: C

テストピラミッドでは、底辺のユニットテストを最も多く（約70%）書くことが推奨されます。ユニットテストは高速で安定しており、保守コストが低く、問題の特定が容易です。上位のテスト（E2E、手動テスト）ほど遅く不安定で、コストが高くなります。

Q2. 「1〜100の整数を受け付ける」仕様に対して、境界値分析でテストすべき値の組み合わせとして最も適切なものはどれですか？

• A) 50, 51
• B) 0, 1, 100, 101
• C) 1, 50, 100
• D) -100, 0, 50, 100, 200

正解: B

境界値分析では、有効範囲の境界とその前後の値をテストします。「1〜100」の場合、下限の境界値 0（無効）と 1（有効）、上限の境界値 100（有効）と 101（無効）が必要です。50は範囲内の代表値（同値分割）であり、境界値ではありません。

Q3. TDDのRed-Green-Refactorサイクルの正しい順序はどれですか？

• A) 実装 → テスト → リファクタリング
• B) テスト作成（失敗）→ 最小限の実装（成功）→ リファクタリング
• C) リファクタリング → テスト → 実装
• D) テスト作成（成功）→ 実装 → リファクタリング

正解: B

TDDのサイクルは: (1) Red = 失敗するテストを書く、(2) Green = テストを通す最小限の実装を行う、(3) Refactor = テストが通る状態を維持しながらコードを改善する、です。テストは最初は必ず失敗する状態（Red）から始めます。

Q4. コードカバレッジが100%であっても、品質が保証されないのはなぜですか？

• A) カバレッジツールが不正確だから
• B) カバレッジは「コードが実行された」ことしか示さず、テストのアサーションの質やエッジケースの網羅性を測れないから
• C) 100%のカバレッジは技術的に不可能だから
• D) カバレッジは行カバレッジしか測定できないから

正解: B

カバレッジはコードが「実行されたかどうか」を測定するだけで、テストの「質」は測定できません。例えば、divide(2, 1) だけで行カバレッジ100%を達成できますが、0除算のケースはテストされていません。アサーションが不十分なテストでもカバレッジは上がります。

Q5. デシジョンテーブルが最も有効なテスト設計場面はどれですか？

• A) 1つの入力値の範囲チェック
• B) 複数の条件の組み合わせによって結果が異なるロジック
• C) 文字列のフォーマットチェック
• D) パフォーマンステスト

正解: B

デシジョンテーブルは、複数の条件の組み合わせによって結果が変わるロジックのテストに最適です。例えば「会員/非会員 x 金額 x 離島/通常」のような3条件の組み合わせを漏れなく整理できます。1つの入力の範囲チェックには境界値分析が適しています。

結果

4問以上正解の場合

合格です。Step 4 に進みましょう。

「テスト設計の基礎はOKだ。次はいよいよ実践。 Jest、Playwright を使ってテストを書いていくぞ」

3問以下の場合

もう少し復習しましょう。

次のステップへ

Step 4 では、実際のテストフレームワークを使ってテストを書きます。ユニットテスト（Jest/Vitest）、インテグレーションテスト、E2Eテスト（Playwright）を実践的に学びましょう。

推定読了時間: 15分