技術書籍

12章 プラクティス8 設計は最後に行う 内容 ソフトウェア開発では、保守性の設計は最後にしたほうが良い傾向がある。プロジェクトの終盤の方が、システムの全体に対して理解が深くなっており、適用させるデザインパターンの判断もしやすくなる。実現の手段として、ユニットテストのサポートを受けながら、再設計とリファクタリングを行う。 反復開発は設計を創発する。創発とは、最初の設計よりも開発が進むに連れ、もっと良い設計が見えてくることを指す。 12.8 創発する設計 原則として、テストファースト開発を行いながら、理解容易性、テスト容易性に注意を配りながら開発していけば、修正しやすいプログラムになり、あとから生まれた設計を取り込むことも、テストがサポートしてくれる。 創発した設計を取り込むことができないということは、修正がしづらいことを意味し、それを続けているといずれ保守可能でないシステムになり、システムはビジネスの拡張についていけなくなるし、エンジニアたちも苦しむことになる。 学び 保守性を加味した設計とリファクタリングは、テストが書かれている前提であれば、プロダクトの全体像が見えるプロジェクトの後半が適している。 テストファースト開発は創発した設計を取り込むことができる。 最初に設計しきるのは現実的ではない。だから、創発した設計を取り込めるプロセスを作ることが重要だ。 学びを活かすアイディア・行動 まずは実践し、メンバーに手法として展開する テストコードの目的の事前知識整理

11.12.2 バグを修正する７つの戦略 内容 バグ修正は大きなコストとなる。そのための７つの戦略の紹介。 戦略 説明 そもそもバグを作らない そのまま。ツールを駆使してヒューマンエラーを減らそう。 できるだけ早くバグを見つける 自動回帰テスト環境を作ってフィードバックを早くし、バグ発見を早くしよう。 バグを見つけられるように設計する カプセル化されていれば、バグは特定しやすくなる 正しい質問をする まず何が正しいのかを明確にする。その次にどこにギャップが有るのかを明確にする。 バグをテストの不足とみなす バグを見つけたら修正する前に失敗するテストを書き、その後にコードを修正する。バグは誤った想定のもと起きるので、まず何が誤った想定なのかを把握し、ユニットテストで具体化する。そうすることで二度と再現しなくなる。 欠陥をもとにプロセスを修正する バグが見つかったら、なぜそのバグが発生したかを、開発プロセスの観点で確認する。開発プロセスに原因があるのであれば、ツールでヒューマンエラーを防げないか検討する。 失敗から学ぶ ↑に似ている。バグを教訓に設計、プロセスを修正する方法を探す。 学び バグが起きたら再発防止フローを徹底する。なぜ起きたのか、どんな種類のバグなのか、ツールで防ぐことができないか、開発プロセスが原因ではないか。 学びを活かすアイディア・行動 現場にレトロスペクティブの観点として展開できる。

11.12 実践しよう 11.12.1 テストを仕様として使うための７つの戦略 内容 テストを文書のようにすることで生きた仕様になる。そのための７つの戦略を紹介する。 戦略 説明 テストを文書のように扱えるようにする テストのコードも、マジックナンバーをハードコードせずに意味がわかる変数名にする 意図がはっきりわかるヘルパーメソッドを使う セットアップの処理や、そのほかの機能を独自のヘルパーメソッドでラッピングすることで、個々のテストの重複を排除しつつも、異なるセットアップオプションを用意できるようになる 何が重要なのかを明らかにする １と似ている。マジックナンバーをハードコードせずに変数で読めるようにして、意図するところをわかるようにする 実装ではなくふるまいをテストする 具体的な実装に合わせてテストするのではなく、テストメソッド名を表すことをテストする。悪い例：testConstructor 。単純すぎる。良い例：testRetrievingValueAfterConstruction 。何をテストしたいのかがわかる。 モックを使ってワークフローをテストする アサーションは値やふるまいをテストできるが、ワークフローやオブジェクト間の相互作用はテストできない。これはモックを使ってテストする。 書きすぎない 微細に記載することは簡単だが、意味が同じテストは重複である。例えば、境界値とその間の値の場合、その間の値のパターンは無尽蔵にあるが、実施するのは１つでよい。それ以外は実施した１つのテストと意味が同じだ。重複したテストは削除する。 正確な例を使う 実際の使われ方を実行することによって、コーディングを開始する前に、矛盾や設計上の問題が明らかになり、早期に対処できる 学び プログラマでない人でも読めるように書くべし 重複は省くべし 相互関係のテストはモックを使うべし ふるまいを明確にテストすべし 学びを活かすアイディア・行動 現場のユニットテストのコーディング規約づくり

11.10 モックを使ったワークフローテスト 内容 ユニットテストは一連の順序を検証したり、似たようなほかのシナリオを検証することは出来ない。こういう場合は、ワークフローテストを行う。 ワークフローテストは実際のオブジェクトを使うのではなくモックを使う。 モックは外部との依存関係とどのように相互作用するかを検証するために使う。 テストとしては、モックが正しいパラメータで呼び出されたかを検証する。 11.11 セーフティネットを作る テスト駆動開発はソフトウェアを作るためのリズムや、開発者が安全にコードを書くためのセーフティネットを提供してくれる。 アクロバットをする人にとってのセーフティネットは命を守るものだが、開発者にとってのセーフティネットは、心理的な保証だ。 テストファースト開発を行う最大の利点は、ソフトウェア開発者がテストしやすいコードを書くようになり、維持するコストも抑えられること。 開発者は設計から始めるように教えられるが、プロジェクトの後半のほうが正しい設計についてはるかに多くのことがわかるため、最後に設計をするのが良い。最後に設計する説明は次の章。 学び 外部との依存関係と相関関係をテストするのはワークフローテストと呼ぶこと ワークフローテストもモックを使って行うこと テストファースト開発は開発者に心理的安全を保証してくれて、結果的にコストを抑えることができる。心理的安全は、心に余裕を生み、焦って汚いコードになることを防ぎ、保守性、テスト容易性を保つことができ、結果的に拡張コストを少なくすることができる。 学びを活かすアイディア・行動 テスコードの目的のための事前知識整理

10.10.1 優れた受け入れテストのための７つの戦略 内容 受け入れテストは、開発者に何を作る必要があるのか、何がいちばん重要なのか、いつ終わるのかを教えてくれる。機能がどうなると終わるのかを知ることで、開発者が作りすぎるのを防ぐことになる。 ここでは10章（10.1.1）で伝えた内容で「受け入れテスト」について実際にどうやって実践する、有効な７つの戦略を説明している。 戦略 補足 作っているものが何に役立つのか明確にする そのまんま 誰が何のために何をしたいのかを知る そのまんま 受け入れ基準を自動化する ？ エッジケース、例外、代替パスを表す ？ 例示を使って具体化し、矛盾を一掃する ？ 受け入れ基準とふるまいの分離 ？ 各テストを一意にする ？ 学び まだよくわからない。 要勉強。

11.1 レッド／グリーン／リファクタリング 内容 テストファースト開発には３つのことなるフェーズがある。 レッド／グリーン／リファクタリング だ。ユニットテストフレームワークの視覚効果が由来する。 レッドテストを失敗「させる」（コンパイルエラーも含まれる）。コンパイルエラーが起きたら「スタブアウト」を作り、テストを失敗させる。 グリーンすべてのテストを成功させる。 リファクタリングコードからリファクタリングし、テストをリファクタリングする 一つのユニットテストを作る中で、この３つのフェーズを繰り返し行っていく。一つのユニットテストというのは、1アサートという意味ではなく、1つのインターフェースに対してかかっている。1インターフェース：複数アサートはあり得る。 11.2 テストコードの例 Parsonという名前と年齢を持つクラスのテストを例にしてテストを解説している。 レッドのフェーズ。クラスが一つも無いところからハッピーパスのテストを書き始める。内容は、Personクラスのコンストラクタに渡した名前と年齢の値がPersonクラスの getName() と getAge() で取得した値と同じかどうかをテストする。クラスは無いのでコンパイルエラーが発生する。 コンパイルエラーのみ解消するために、Personクラスをスタブとしてとして作成してコンパイルエラーの部分を解消。スタブはクイックフィックス機能で作成し、メソッド返却値はダミーのままにすること。テストはコンパイルエラーが解消するので実行すると、返却値がダミーなのでエラーとなる。最初の目的はテストを失敗させることなのでOK。 グリーンのフェーズ。テストが通るようにプロダクトコードを修正する。コンストラクタの引数をメソッドで返すように実装する。 11.3 制約を導入する Personクラスの年齢に負の数を入れると年齢としてはおかしくなるので、そういった不備をなくすために制約を入れる。そういう場合の解説。ここでもテストファーストで書きながら説明している。 Personクラスに最大と最小の定数のテストを書く レッドフェーズ。 Personクラスに最大と最小の定数を記述しコンパイルエラーを出す。 コンパイルエラーをクイックフィックスを使い解消 実行すると失敗するのでレッド完了。 グリーンフェーズ。 Personクラスの最大値、最小値の値を適切に設定して実行。OKとなりグリーン完了。 次にコンストラクタの引数・年齢に最小値より小さい値を入れたらエラーとなるテスト レッドフェーズ 投げられるとOKとなる例外クラスをテストに書いてコンパイルエラーを起こす。 コンパイルエラーの例外クラスはクイックフィックスで作成し、コンパイルエラーを解消。 実行すると失敗するのでレッド完了。 グリーンフェーズ Personクラスのコンストラクタ内で最小値より小さい場合に例外を投げる処理を追加して実行。OKとなりグリーン完了。 次にコンストラクタの引数・年齢に最大値より大きい値を入れたらエラーとなるテスト 最小値のテストと同じ要領で最大値のテストを追加してグリーンまで完了させる。 リファクタリング 最小値と最大値で違う例外を投げるようにしたが、範囲外を表す１つのクラスにした方が使い勝手が良さそうなため、そちらを使うようにする。 11.4 作ったもの 11.2 – 11.3 で作ったものを通しての要点は「テストは仕様であり、テストは不要に重複しないように作る」のがポイントと言っている。 学び テストメソッド名に関する名前重要。何をテストしているかが分かれば、冗長でも構わない。何をテストしているかと仕様がわかることが重要。 コンパイルエラーの解消はクイックフィックスで解消していくことで、コードのタイプミスを減らせる。 レッドのフェーズは、コンパイルエラーからテストを実行して失敗させること。 最大値、最小値などの値よりも定数の名前が重要。境界値は時代の変化に合わせて変わるかもしれないが、重要なのは簡単に変えられるようにしておくこと。 例外をテストする方法。 レッド／グリーン／リファクタリングの3つのフェーズの基本。 テストコードは「失敗をさせ、正しいコードにすることで保証されたものとなる」で、このためにレッド／グリーンのフェーズがある。 …

11 プラクティス7 テストでふるまいを明示する 内容 テストによって動くものと動かないものがすぐにわかる。これは開発の原動力を大きく影響を及ぼす。 ケイパー・ジョーンズは「開発者の時間の半分以上が、過去にやった仕事の手直しに費やされている」と言っている。例えば、不具合の原因が2箇所による複合的な要因の場合、その原因を特定するのは非常に時間がかかるが、ありえる。この手直しに時間がかかっていることが、テスト駆動開発を行う理由だ。 マネージャーがテスト駆動開発する時間を持てないというのは、以下のループとなっているためだ。 テスト駆動開発をしていないから、問題の原因の特定に時間がかかる 問題の原因の特定に時間をかけすぎてるから、テスト駆動開発を学習する時間がとれない このループになっているのであれば、ここから降りなければならない。 テストは具体的な要件であり、メソッドの使い方を正しくフォーカスすることができる。これは実装を良くするためや、問題をとりのぞくために非常に効果がある。 学び ほとんどの時間を読む時間、調査する時間に費やしているという事実 テスト駆動開発をしていないからテスト駆動開発ができないループに入っている場合、なんとかしてそのループを抜け出なければならない 学びを活かすアイディア・行動 テストコードの目的のための事前知識整理

10.11 本章のふりかえり 内容 正しいユニットテストの書き方で書けば、コードのリファクタリングのサポートをしてくれて「CLEAN」なコードにつながる。 テスト駆動開発は正しく行わないと、保守可能な効果はなくなる。 学び 内容の通り 学びを活かすアイディア・行動 特になし

10.10.2 優れたユニットテストのための７つの戦略 内容 ユニットテストのための大切な７つの観点を説明している。 戦略 補足 呼び出し側の視点に立つ 呼び出し側は何を必要としているのか、何を渡す必要があるのか。 テストを使ってふるまいを表す 仕様がわかるドキュメントになるようにわかりやすく書く。テストを最新に保つことが、ドキュメントを最新に保つことになる。 新しい違いを生み出すテストだけ書く テストは一意にする。観察可能なテストにして無駄なテストをなくす。 失敗したテストにパスするためのコードのみを書く まず失敗するコードを書き、テストが通るコードに書き直す。このルールに則った場合に「テストが通ったら正しい」という保証になる。 テストを使って、ふるまいを作る ハッピーパスから作るにしろ、例外からにしろ、テストから作る コードをリファクタリングする 反復開発する場合、保守性は重要だからリファクタリングをして保守可能な状態にする テストをリファクタリングする 実装に依存したテストではなくふるまいを表したテストを書いていなければ不要に修正する必要はない。ただし、テストもコードであるため保守可能な状態にしないとコード品質に影響する可能性がある。 学び テストはコードだという認識。保守可能な状態にリファクタリングする必要がある。 テストはふるまいを表すべき。実装に依存したかたちにしてしまうと不要に修正する必要の可能性が出てくるし、そうなると保守できなくなる。 テストは仕様を表す最新のドキュメント。実行することでプログラムが正しいことを表すため、仕様がわかるように書くことで、最新のドキュメントとなる。メソッドコメントのように変更し忘れがなくなる。 学びを活かすアイディア・行動 現場のユニットテストのコーディング規約づくり

10.8 テスト駆動開発をチームに広める 内容 テスト駆動開発の正しいやり方を身につける唯一の方法なんてものは存在しないが、まずは、良い共通理解を形成するところから始める。 テスト駆動開発導入にあたって足かせになるのは、経営者と開発者それぞれ異なったテスト駆動開発に対する負の先入観。これらを統一した共通認識にするところから始める必要がある。 10.9 テストに感染する 開発者の最初の大きな課題は最初にテストを書くことが不快だということだ。なぜ不快かというと、実装を集中して書くことを訓練してきたからだ。その習慣をやめて最初にテストを書くようになるまで長い時間がかかる。 開発者は「目的」と「やり方」の世界を行き来するが、まず「作るものは何か」（目的）から始めるべきだ。それがインターフェイスであり、テストだ。 まず、呼び出すメソッドの外観、名前、入力パラメーター、戻り値を明らかにする。それから「どうやって作るか」に焦点を合わせる。 一直線にプロダクションコードを書くという習慣をやめれば、自然にテストファーストに考えられる。この現象を、テスト駆動開発の初期提案者の1人エリック・ガンマ氏が「テストに感染し始めた」と言った。 学び チームに導入したければ、経営者、開発者はそれぞれの観点でメリット、デメリットを整理して共通認識になるように準備する必要がある。 テストを最初に書く違和感の直し方は、「作るものは何か？」（外観、名前、入力パラメータ、戻り値）を明確にし、そのテストを書くところから始めよう。 最初にテストを書く習慣が開発者にはない。 学びを活かすアイディア・行動 テスト駆動開発のメリデメの整理。経営観点と開発観点。 テストコードの目的の事前知識整理