7-1. 演習問題

問題1：選択問題

1-1. ユニットテストの説明として最も適切なのはどれか。

A. 関数やクラスなど小さな単位の動作を確認するテスト
B. ブラウザを使って利用者の操作を再現するテスト
C. データベースとの通信速度を計測するテスト

解答と解説

正解：A. 関数やクラスなど小さな単位の動作を確認するテスト

A が正しい。ユニットテストは最小単位の動作を確認する。
B は誤り。ブラウザ操作を再現するのは E2Eテストの特徴である。
C は誤り。通信速度の計測はパフォーマンステストであり、ユニットテストではない。

ユニットテストは外部依存なしに実行でき、最も速くフィードバックを得やすい。

1-2. 統合テストの主な目的として最も適切なのはどれか。

A. 複数の部品が組み合わさったときの連携を確認する
B. 関数1つのエッジケースを細かく確認する
C. 画像の表示崩れを目視で確認する

解答と解説

正解：A. 複数の部品が組み合わさったときの連携を確認する

A が正しい。統合テストは部品間の連携部分を確認することが主目的である。
B は誤り。エッジケースの細かい確認はユニットテストに向いている。
C は誤り。目視確認は自動テストではない。

ユニットテストが全部通っていても、データの受け渡し形式が合わなければ実際には動かないことがある。

1-3. E2Eテストの特徴として最も適切なのはどれか。

A. 最も速く、最も安定している
B. 利用者の操作フローを端から端まで通す
C. スタブやモックだけを使って外部依存をゼロにする

解答と解説

正解：B. 利用者の操作フローを端から端まで通す

B が正しい。E2Eテストは利用者目線で全体の流れを確認する。
A は誤り。E2Eテストは最も遅く、最も不安定になりやすい。
C は誤り。外部依存を排除するのは E2Eテストの特徴ではなく、むしろ実際の環境に近い状態を使う。

E2Eテストは「利用者が実際に使えるか」を確認する最後の砦である。

1-4. テストピラミッドの考え方として最も適切なのはどれか。

A. ユニットテストを多く・E2Eテストを少なくする
B. E2Eテストを最も多くする
C. 3種類すべてを同じ数にそろえる

解答と解説

正解：A. ユニットテストを多く・E2Eテストを少なくする

A が正しい。テストピラミッドはユニットテストを最多にする考え方である。
B は誤り。E2Eテストを多くすると遅くて不安定なテスト群になりやすい。
C は誤り。等比率にすべきという考え方ではない。

速く安定したフィードバックを得るためには、ユニットテストを厚くすることが重要である。

1-5. スタブの役割として最も適切なのはどれか。

A. 固定の戻り値を返すニセの部品
B. 本番データベースをそのまま使う部品
C. ブラウザのキャッシュを消去する仕組み

解答と解説

正解：A. 固定の戻り値を返すニセの部品

A が正しい。スタブは固定値を返すニセの部品である。
B は誤り。本番データベースを使うのはスタブではない。
C は誤り。キャッシュ削除はスタブとは無関係である。

スタブを使うと外部依存なしに特定の状態を再現し、ビジネスロジックだけを集中してテストできる。

1-6. ユニットテストが全部通っていても統合テストが必要な理由として最も適切なのはどれか。

A. 各部品の内部実装が正しくても、連携部分でズレが起きることがあるから
B. ユニットテストは信頼できないから
C. ユニットテストはブラウザが起動しないから

解答と解説

正解：A. 各部品の内部実装が正しくても、連携部分でズレが起きることがあるから

A が正しい。部品単体は正しくても、組み合わせるときの I/F のズレで壊れることがある。
B は誤り。ユニットテストは信頼できる。役割が違うだけである。
C は誤り。ブラウザの有無はユニットテストと統合テストの差ではない。

「部品は正しいが、接続部分が間違っていた」というバグは統合テストで見つけやすい。

問題2：穴埋め問題

次の文章の空欄を埋めてください。

関数やクラスなど小さな単位を確認するテストを （　　　） テストという。
複数の部品の連携を確認するテストを （　　　） テストという。
利用者の操作フローを端から端まで通すテストを （　　　） テストという。
ユニットテストを多く・E2Eテストを少なくする考え方を （　　　） という。
固定値を返すニセの部品を （　　　） という。
バグ修正後に以前動いていた部分が壊れていないか確認することを （　　　） テストという。

解答欄

解答と解説

ユニット

最小単位の動作を確認する、最も基本的なテストである。

統合

部品間の連携・インタフェースを確認するテストである。

E2E（エンドツーエンド）

利用者の操作フローを実際の環境に近い状態で通すテストである。

テストピラミッド

ユニットテストを最多にすることで、速く安定したテスト群を作る考え方である。

スタブ

固定値を返すニセの部品で、外部依存なしにテストの前提条件を設定できる。

回帰

修正後に以前の動作が壊れていないかを確認するテストである。

問題3：記述問題

3-1. ユニットテスト・統合テスト・E2Eテストをそれぞれ「速度」「確認できる範囲」の観点で比較してください。

解答欄

解答と解説

3-1. 3種類の比較

ユニットテストは最も速く、外部依存がないため安定しやすい。確認範囲は関数・クラスなど小さな単位に限られる。統合テストはDBや外部サービスを使うため中程度の速度で、確認範囲は複数コンポーネントの連携まで広がる。 E2Eテストはブラウザ操作から DB まで全体を通すため最も遅く、外部依存が多いため不安定になりやすい。確認範囲は最も広い。

3-2. テストピラミッドでユニットテストを多く・E2Eテストを少なくする理由を説明してください。

解答欄

解答と解説

3-2. テストピラミッドの理由

E2Eテストだけに頼ると、実行が遅くなり不安定にもなりやすい。テストが遅いと実行する機会が減り、バグの発見が遅れる。ユニットテストを厚くすると速いフィードバックを得やすく、問題を早期に発見しやすい。そのため「土台となるユニットテストを多く、上のE2Eテストは重要な経路に絞る」という分布が推奨される。

3-3. スタブやモックを使うメリットと、使いすぎるリスクを説明してください。

解答欄

解答と解説

3-3. スタブ・モックのメリットとリスク

メリットは、データベースや外部APIがなくてもテストを実行できることで、速く・安定して動く環境を作れる。リスクは、スタブが実際の動作と乖離してしまうと「テストは通るが本番では壊れる」状態になることである。そのため、何を確認したいかに合わせて、実物を使うか偽物を使うかを慎重に選ぶ必要がある。

3-4. バグが見つかったときにテストを書くことが、なぜ重要なのか説明してください。

解答欄

解答と解説

3-4. バグが見つかったときにテストを書く重要性

テストなしで直すと、同じ原因でバグが再発したときに気づきにくい。バグが見つかった時点でテストを書いておくと、その失敗ケースが永続的に確認対象になる。これにより「同じバグが再び起きても、今度は即座に検出できる」という安全網ができる。

問題4：ハンズオン

テストが先に書かれている。calcTax と formatPrice を実装して全テストを ✅ PASS にせよ。

取り組む内容

calcTax を実装する（バリデーション2つ＋ Math.round(price * rate) を返す）
formatPrice を実装する（バリデーション1つ＋ toLocaleString("ja-JP") + "円" を返す）
実行して全テストが ✅ PASS になることを確認する
calcTax から Math.round を外してみて、333円の10% のテストが ❌ FAIL になることを確認する

実行プレイグラウンド

編集内容は自動保存されます / Ctrl+Enter でも実行できます

// TODO: calcTax を実装する
// バリデーション: price < 0 → throw new Error("price must be >= 0")
// バリデーション: rate < 0 || rate > 1 → throw new Error("rate must be 0-1")
// 戻り値: Math.round(price * rate)
function calcTax(price, rate) {

}

// TODO: formatPrice を実装する
// バリデーション: typeof price !== "number" → throw new Error("price must be a number")
// 戻り値: price.toLocaleString("ja-JP") + "円"
function formatPrice(price) {

}

// ---- テストフレームワーク（変更不要）----
function assertEqual(actual, expected, label) {
if (actual === expected) {
  console.log(`✅ PASS: ${label}`);
} else {
  console.log(`❌ FAIL: ${label} — expected ${expected}, got ${actual}`);
}
}
function assertThrows(fn, label) {
try {
  fn();
  console.log(`❌ FAIL: ${label} — expected an error but none was thrown`);
} catch (e) {
  console.log(`✅ PASS: ${label} (threw: ${e.message})`);
}
}

// ---- テスト（変更不要）----
assertEqual(calcTax(1000, 0.1), 100, "1000円の10%の税は100円");
assertEqual(calcTax(0, 0.1), 0, "0円の税は0円");
assertEqual(calcTax(1000, 0), 0, "税率0の税は0円");
assertEqual(calcTax(333, 0.1), 33, "333円の10%は33円（四捨五入）");
assertThrows(() => calcTax(-1, 0.1), "負の価格は例外を投げる");
assertThrows(() => calcTax(1000, 1.5), "1超の税率は例外を投げる");

assertEqual(formatPrice(1500), "1,500円", "1500円のフォーマット");
assertEqual(formatPrice(0), "0円", "0円のフォーマット");
assertThrows(() => formatPrice("abc"), "文字列は例外を投げる");

出力

「実行」を押すと、ここに結果が表示されます。

確認したいポイント

全テストが ✅ PASS になることを確認する
calcTax から Math.round を外すと 333円の10% のテストが ❌ FAIL になることを確認する（テストの価値）
テストが先に書かれているため、実装の「正解」が明確になっていることを確認する

解答と解説

② そのまま実行したときの見方

全テストが ✅ PASS になれば、関数が仕様通りに動いていることを確認できる。 assertEqual は実際の値と期待値を比較し、assertThrows は例外が正しく投げられるかを確認している。このように「1つの関数に対して複数のケースを並べる」のがユニットテストの基本形である。

③ バグを作って失敗させたとき

Math.round を外すと、333 × 0.1 = 33.3 が返り、期待値 33 と一致しないため ❌ FAIL になる。テストが失敗することで「どの関数の、どの動作が壊れたか」をすぐに特定できる。これが、テストを書いておく価値の一つである。

④ テストを追加したとき

calcTax(999, 0.1) は 99.9 となり、Math.round で 100 になる。したがって期待値は 100 が正しい。

このように、期待値が正しいかどうかをテストを書きながら考えることで、仕様の確認にもなる。

図で見る

ユニットテスト
  ↓
関数 calcTax に対して
正常系・境界値・エラーケースを並べる
  ↓
どこが壊れたかを素早く特定できる

実際のテストフレームワーク（Jest・JUnit・pytest など）を使うと、 assertEqual や assertThrows の代わりに expect(...).toBe(...) のような専用の記法が使えるようになる。