第13章 テストとコード品質

Slide 01. テスト、TDD、コード品質

第13章では、支援ステータス機能を、テストとコード品質の観点から確認します。ここで目指すのは、テストをたくさん書くことそのものではありません。何を守りたいのか、どのリスクを確認するのか、変更後も壊れていないとどう説明するのかを整理し、あとから変更し続けられる状態へ近づけます。

Slide 02. この章で持ち帰ること

この章で持ち帰ってほしいのは、受け入れ条件、API契約、画面状態を、テストで何を見るかに置き換える考え方です。正常に動く一例だけでなく、入力不正、権限なし、保存失敗、回帰確認も見ます。最後は、確認結果とコードの気になる点をquality-review、つまり品質レビューのメモとして説明できる状態を目指します。

Slide 03. 第9章から第12章との接続

第9章では受け入れ条件を書きました。第10章ではデータ構造を決め、第11章ではAPI契約と確認ログを作りました。第12章では画面状態とブラウザ確認を扱いました。第13章では、これらを材料にして、何を自動テストで守り、何を手動確認に残すかを決めます。

Slide 04. テストの目的

テストの目的は、完璧な証明をすることではありません。期待したふるまいが今も動いていること、あとから変更しても壊れていないことを確認しやすくすることです。テストがあると、修正するときに不安が減ります。自分だけでなく、未来の自分やレビュアーにも安心材料を渡せます。

Slide 05. 手動確認と自動テスト

手動確認と自動テストは、どちらか一方だけで十分というものではありません。自動テストは、同じ確認を何度も安定して繰り返すのに向いています。一方で、画面の分かりやすさ、文言、フォーカス、操作感は手動確認が大事です。役割を分けて、確認したいリスクに合う方法を選びます。

Slide 06. 受け入れ条件からテスト観点へ

テスト観点は、思いつきで並べるものではありません。第9章の受け入れ条件、第11章のAPI契約、第12章のui-state-model、つまり画面状態の一覧を読み、テストで確認したい動きに置き換えます。たとえば、担当メンターは変更できる、担当外メンターは変更できない、不正なstatusは保存されない、という観点が出てきます。

Slide 07. 正常系だけでは足りない

最初は、うまくいく流れだけを確認したくなります。でも実務では、失敗時のふるまいも重要です。不正な入力、権限なし、対象なし、一覧取得失敗、保存失敗、0件表示、二重送信。こうしたケースを先に挙げておくと、あとで慌てて条件を足すのではなく、設計として確認できます。

Slide 08. テストの種類

テストには種類があります。単体テストは小さなロジックを速く確認します。APIテストは、送ったrequestと返ってきたresponse、必要ならDBに残った値を見ます。画面確認やE2Eは、画面操作から最後までの流れを見ます。どれが偉いかではなく、どのリスクをどこで確認するのが自然かを考えます。

Slide 09. 単体テスト

単体テストは、小さな関数やロジックを素早く確認するために使います。支援ステータス機能なら、status、つまり支援ステータスの値の変換、不正なstatusの拒否、APIのエラー番号から画面文言への変換などが候補です。画面全体を動かさなくても確認できる小さな判断を、読みやすいテストにします。

Slide 10. APIテスト

APIテストでは、HTTPのrequestを送り、responseが返るまでを確認します。支援ステータスを更新できるか、担当外なら403、つまり権限なしになるか、不正なstatusなら422、つまり入力エラーになるかを見ます。返ってきた番号、返事の中身、DBに残った値を一緒に見ると、API契約と実装が合っているかを説明しやすくなります。

Slide 11. 画面確認

画面確認では、利用者の操作に近い流れを見ます。一覧が表示されるか、保存中が分かるか、保存成功や保存失敗が表示されるか、NetworkとConsoleに問題がないか。第12章で作ったfrontend-check-logを使うと、目視だけで終わらず、画面とAPIのつながりまで確認できます。

Slide 12. TDDの基本

TDDは、Test Driven Developmentの略で、先に小さなテストを書いてから実装する進め方です。redでは、期待するふるまいをテストにして、まず失敗を確認します。greenでは、最小限の実装でテストを通します。refactorでは、ふるまいを変えずに名前や重複を整えます。大事なのは、先に小さく期待を言葉にすることです。

Slide 13. TDDが向く場面

TDDは、すべての作業に無理に当てはめるものではありません。小さなロジック、入力検証、値変換、バグ修正の再現テストには向いています。逆に、まだ要件が大きく揺れている画面全体では、先に手を動かして形を見た方がよいこともあります。使いどころを選んで、小さく試します。

Slide 14. 最初のテストを選ぶ

最初から全分岐を網羅しようとすると、手が止まりやすくなります。まず、壊れると困る重要なふるまいを選びます。支援ステータスなら、担当メンターだけが更新できること、不正なstatusを拒否すること、保存結果が画面に反映されることが候補です。重要なものから確認を積みます。

Slide 15. テスト名

テスト名は、将来の読者への説明でもあります。testUpdateのような名前では、何を守るテストか分かりません。「担当メンターは担当受講者の支援ステータスを要支援に変更できる」のように、前提、操作、期待結果が見える名前にします。失敗したときに、何が壊れたのか分かる名前がよいテスト名です。

Slide 16. テストデータ

テストデータが読みにくいと、テストの意図も読みにくくなります。コード上の名前は、担当メンター、担当外メンター、担当受講者のように役割が分かるものにします。fixtureやfactoryは、テストデータをまとめて用意する仕組みです。便利ですが、前提を隠しすぎないようにします。読みやすさと独立性を大切にします。

Slide 17. mockとstubの入口

mockやstubは、本物の外部サービスの代わりに使うテスト用の部品です。たとえば外部APIや時刻、メール送信のように、毎回本物を動かすと不安定なものを置き換えることがあります。ただし、置き換えすぎると実際の接続の問題を見落とします。何を本物で確認し、何を代わりの部品で確認するかを意識します。

Slide 18. 回帰確認

回帰確認は、直したことだけでなく、既に動いていたことを壊していないかを見る確認です。支援ステータス更新を直したら、一覧表示、絞り込み、保存後の表示、権限なしの挙動も必要に応じて確認します。バグ修正では、同じバグが戻らないように再現テストを残すと効果があります。

Slide 19. リファクタリング

リファクタリングは、ふるまいを変えずにコードの構造を良くすることです。名前を分かりやすくする、重複を減らす、長い関数を分ける、役割を分ける。見た目を整えるだけではなく、次の変更を安全にするための作業です。テストがあると、改善後もふるまいが変わっていないことを確認しやすくなります。

Slide 20. 仕様変更と分ける

仕様変更とリファクタリングを同じ差分に混ぜすぎると、レビューが難しくなります。何が新しいふるまいで、何が構造整理なのかが見えなくなるからです。可能なら、ふるまいを変える差分と、ふるまいを変えない改善を分けます。分けられない場合も、Pull Request、つまりレビュー依頼の説明で意図を明確にします。

Slide 21. 内部品質

内部品質は、利用者から直接は見えにくいものです。しかし、名前が分かりにくい、役割が混ざっている、重複が多い、条件分岐が読みにくいコードは、次の変更を遅くします。品質は好みの問題ではありません。レビューしやすさ、テストしやすさ、変更しやすさに直結します。

Slide 22. 技術的負債

技術的負債は、後で直す必要が出る設計や実装上の借りです。すべての負債が悪いわけではありません。時間の制約で意図的に残すこともあります。ただし、その場合は理由、影響、いつ直すか、何が起きたら直すかを残します。何も書かずに放置すると、あとでなぜそうなったのか分からなくなります。

Slide 23. セルフレビュー

Pull Request、つまりレビューに出す変更を作る前に、自分で差分を読みます。テストが通るかだけでなく、確認したこと、確認していないこと、残るリスクを書きます。たとえば、権限なしのAPIテストは確認済み、画面のキーボード操作は未確認、のように書きます。変更意図、確認結果、残課題があると、レビューは進めやすくなります。

Slide 24. AIにテスト観点を頼む

AIには、テスト観点、テストケース、テストコード案、リファクタリング候補を頼めます。貼る前に、実データ、秘密情報、個人情報がないかを確認します。AIが作ったテストは、採用前に実行します。失敗すべきときに失敗するか、通るべきときに通るか、実装詳細に寄りすぎていないかを見ます。Pull Requestには、人が確認した結果として書きます。

Slide 25. 個人開発課題への接続

個人開発課題でも、機能を作って終わりではありません。何をテストで守るか、どの確認を手動に残すか、リファクタリングで何を改善したか、どんな負債を残したかを説明する必要があります。この章の成果物は、PR本文、レビュー、最終発表で品質を説明する材料になります。

Slide 26. Exercise 1

演習1では、test-strategy、つまり何をどう確認するかの方針を書きます。まず、担当メンターだけが変更できることをAPIテストで守る、のように一つ書きます。受け入れ条件、API契約、画面状態を読み、正常系、入力不正、権限、表示状態、回帰確認に分けます。テスト数ではなく、重要なふるまいとリスクから選びます。

Slide 27. Exercise 2

演習2では、test-cases、つまり具体的な確認項目を書きます。まず、担当外メンターが変更すると403になる、のように、前提、操作、期待結果を書きます。続けて、使うテストデータと確認方法を決めます。観点をケースにすると、誰が実行しても同じ確認に近づけられます。

Slide 28. Exercise 3

演習3では、tdd-log、つまりTDDで何を試したかの記録を書きます。まず、不正なstatusを拒否する、のような小さなロジックを一つ選びます。redで失敗するテストを書き、greenで最小限の実装をし、refactorで名前や重複を整えます。最後に、何を変え、何を変えていないのかを記録します。

Slide 29. Exercise 4

演習4では、refactoring-note、つまりふるまいを変えずに直した内容のメモを書きます。まず、長い関数を分けるが保存結果は変えない、のように、変えないふるまいを書きます。改善後は、実行したテストと手動確認を残します。ふるまいを変えない改善だと説明できることが重要です。

Slide 30. Exercise 5

演習5では、quality-review、つまり確認結果と残るリスクのまとめを書きます。まず、APIテストは実行済み、キーボード操作は未確認、のように事実を書きます。差分を読み、実行したテスト、未確認のこと、コード品質の観点、残したリスクをまとめます。自分の変更について、確認済みと言える範囲を説明する成果物です。

Slide 31. 第14章への接続

第13章では、変更し続けるためのテストと品質確認を扱いました。第14章では、そこにセキュリティの観点を加えます。この章で作ったtest-casesやquality-reviewに、入力検証、認可、秘密情報、依存関係の見方を足します。安全に作るための確認は、ここからさらに広がっていきます。