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

10.7 テスト駆動開発は失敗することがある 内容 テスト駆動開発はスキルであり、スキルが十分に習得されていないと、開発者の負荷になり、プロジェクトの進行は遅くなる。それが原因でプロジェクトが失敗するというように判断したのなら、テスト駆動開発をやめるのが正しい。 開発者が対応できないときは、開発者に新しい学習曲線の負担をかけるべきではない。テスト駆動開発を続けてプロジェクトを失敗させ倒産するか、テスト駆動開発をやめるかの選択に直面しているなら、テスト駆動開発をやめることはいちばん確実で正しい。リリースの準備ができているなら、テスト駆動開発の導入に挑戦する必要はない。 テスト駆動開発の間違った会社の例 とある会社ではコードの品質、「CLEAN」なコード、優れた開発原則は導入できていたにもかかわらず、テストの運用がうまくいかなかった。 テストが冗長コードをクリーンにするのに１日、テストをクリーンにするのに１週間かかっていた。原因はテストコードもコードであると見直しておらず、テストの冗長性が非常に高くなっていたため。 インターフェースではなく実装に依存したテストインターフェイスに対してテストするのではなく、実装に対してテストをしていたため、コードのクリーンアップをしようとしたときに、テストをクリーンアップするのが困難だった。 ユニットテストの書き方が違うテストを実行するためにOracleに接続していて、モックを使っておらず実際のDBに接続していたため時間がかかっていた。 テストの量を不要に増やした彼らはQAの立場で「テストが多ければ良いテストだ」と考え、あまりにも多くのテストを書いていた。上記の要因を踏まえ、大量の運用できないテストを作っていた。 学び テスト駆動開発はスキルであり、習得が必要。習得には負荷がかかるので導入は計画的にしなければいけない。 負荷が高すぎたり、間違ったやり方で工数が上がりすぎては本末転倒。 学びを活かすアイディア・行動 ユニットテストのコーディング規約づくり失敗するとどうなるかを書く。

10.6 テスト可能なコードを書く 内容 テスト駆動開発をやっていないし、やりたくもないマネージャーに対して納得させた言葉。 テストファースト開発するかどうかは気にしないが、テスト可能なコードを書くかどうかを気にする。テスト駆動開発はそうするための方法だ。 テスト駆動開発はテストファーストでテストを書くため、自然とテスト可能なコードになる。 うまくいかない状況というのは、設計の問題があって考え直すべきであることを示している。テスト駆動開発は、難易度のダイヤルを持つようなものだ。詰まってしまったときには、いつでも「哀れになるほど簡単」にセットして、そこで少し自信をつけてから難易度を上げる。これを自分自身でコントロールしていくのだ。 このようにして、うまく進めなければ謙虚に前に戻り、設計し直し、最後にはよいテストとテスト可能なコードを作る。 学び テスト可能なコードかどうかが重要。 テスト駆動開発はテストファーストでテストを書くため、自然とテスト可能なコードになる。 間違ったなら、素直に認めて前に戻ろう。 学びを活かすアイディア・行動 テストコードの目的の事前知識整理

10.4 テスト駆動開発はすばやいフィードバックをもたらす 内容 ソフトウェアを開発するいちばん安価な方法は、最初からバグが発生しないようにすることだ。次に安価な方法は、あとで別のチームが修正するのではなく、発見したらすぐに同じ人または同じチームによって修正することだ。 一連の刺激と反応のトランザクションが精神に定着するためには、刺激に対してすばやい反応を続けることが必要だと、ある生物学者は示している。この生物学的観点でも、バグを生んだ本人がすぐ治すのが早いということになる。 そして、テスト駆動開発はすばやいフィードバックをもたらしてくれる。 10.5 テスト駆動開発はリファクタリングをサポートする コードがテストによってサポートされている場合は、リファクタリングが安全にできる。何かを間違えたらテストが失敗してすぐに教えてくれるからだ。 リファクタリングが必要なシーン 視野が狭くなっていると命名が少しずさんになる傾向がある。 ふるまいを実装している最中に、何に命名をする必要があるかわからなくなることがある。 アジャイルはリファクタリングしながら進むと効率的 アジャイル開発では、すべてを最初から理解しようとせず、反復的にソフトウェアを「間違いながら」「設計しながら」作ることが許されており、そのほうがはるかに効率的。そうするためにはリファクタリングしながら進むのは必須で、そのためにはテストが常にサポートしてくれる環境が必要。 学び 記憶を定着させるには反復練習が必要。 レガシーの匂いがするコードは対処を先延ばしにしないようにしないと、レガシーコードを作った本人がいなくなる可能性がある。レガシーコードが残ると拡張しづらいシステムになるので、レガシーコードはなるべくリアルタイムで修正する。 レガシーコードを産まないようにするにはテスト駆動開発とペアプロすると、正しく進んでいくのがよいのではないか。 リファクタリングにはテストを担保するものが常に横にある必要がある リファクタリングは開発中が一番コストをかけずにできる 学びを活かすアイディア・行動 現場にテスト駆動開発をシフトさせる。どうすればいいか。。 現場のリファクタリング計画のためにリファクタリング内容に紐づく修正ファイル対象の一覧を作る。案件があるときに、合わせて修正を検討する。

10.3 良いテストを書く 内容 テスト駆動開発として実践されている「テストファースト開発」と「テストアフター開発」を紹介し、多くの開発者やマネージャーは「テストアフター開発」によって、テスト駆動開発に対するネガティブな誤解を生んでいることを説明している。 テストファースト開発 説明 小さな機能のテストを書いてから、その機能を実装するやり方。 メリット テストの観点（外部からの観察）と、コードの観点（内部からの観察）を行き来することで、フィードバックをもらいながら堅実に進められる。 最初にテストを書くことで、常に100%のコードカバレッジが確保できる。 失敗したテストに合格するようにコードを書くため、テスト可能なコードが書けていることを保証してくれる。 デメリット テストを書くスキルの習得が要る テストアフター開発 説明 コードを書いてからテストを書く。（著者がそう呼んでいる） メリット 自動化された回帰テストを好きなときに作って実行できる。 デメリット コードを書いたあとにテストを書くのは、かなりの再設計、コードをクリーンアップが必要であることがほとんど。結局、テスト可能なコードを最初に作成するほうが楽。 この実態を前提に、多くのマネージャーと開発者は、テスト駆動開発に対し、テストアフター開発のイメージを持ち「やたら手がかかる」というような先入観を持っている。 テストファースト開発では、テストアフター開発のデメリットを防ぐことができる。 すべてのテストを先に書いてから、実装する方法もある。この方法にはいくつかの利点があるのは事実だが、テストファースト開発で得られる頻繁なフィードバックのほうが大きな利点である。著者はすべてのテストを先に書いてから実装する方法はテスト駆動開発とは考えていない。 10.3.1 テストではない テストは二重の役割を果たしているということを説明している。 1つは、仮説であり、ふるまいの仕様。 もう1つは、回帰テストが常に用意されていて実行され、コードが期待したように機能していることを検証すること コードを書く前に書いているユニットテストはテストではなく仮説。サービスの呼び出し方法と期待する戻り値の仮説を立てている。つまり、どうなったら完成するのかの仮説を立てている。 次に、テストに合格するコードを書いたら実際のテストになる。なんらかのふるまいを実行して検証したから。 そしてこの検証機能はソフトウェアの寿命が来るまで以下の価値を提供し続ける。 影響を与える可能性のあるものは何も変わっていないことを保証する コードが期待したように動くことを保証する 10.3.2 ふるまいの集合体 ユニットとはふるまいの単位で独立した検証可能なふるまいのこと。つまり、どのように使ってどのような結果になるかを検証できるふるまいのこと。ふるまいを表すために、常に必要最小限のテストを書くことが重要。 多くの開発者は「ユニットテスト」の「ユニット」と言う言葉を、メソッド、クラス、モジュール、関数などのような実体を指すものと勘違いするが、違う。この勘違いのため、新しいクラスやメソッドを作るたびに新しいテストを作成し、コードの成長とともに多くのテストを追加することで、肥大化するのではないかと心配したり、実際に追加してしまう。 テストファーストのメリットは、必要に応じてあとから簡単にコードをクリーンアップできるようにすることだ。ユニットの単位を勘違いして、コードをクリーンアップするときに、不要なテストを増やしてしまうと、自動回帰テストを持つことの価値の大部分を失ってしまう。 「ユニット」が表現するのはふるまいだ。ふるまいが変わらないなら、テストを変える必要はない。 「ユニットテスト」は「すべてのクラスやメソッドがテストを持つべき」ではなく「あらゆる観察可能なふるまいが、それに紐づくテストを持つべき」である。「あらゆる観察可能なふるまい」＝「すべてのクラスやメソッド」というわけではない。 学び 実際にテストアフター開発が起きているからネガティブな先入観が生まれる。では、なぜテストアフター開発をしてしまうのか。要因は、大きく２つ。 傲慢。ほとんどの開発者はテスト可能でないコードを書いてしまう前提を認識していない。 無知。テストファースト開発が習得が必要なスキルだということを知らない。 間違った認識、無知は失敗を生み、ネガティブな先入観を生む。 テストファーストで書くテストは、実際のコードまで書いて、テストとなる。テストだけの時点では、ふるまいの仕様を表す仮説である。 自動回帰テストの環境がないと効果が薄いように感じる。 ユニットとは観察可能なふるまいの単位である。 ユニットの単位を明確にして不要なテストを増やしてはいけない。 学びを活かすアイディア・行動 テストコードの目的のための事前知識準備 現場の回帰テスト環境作り ユニットの単位の深堀り 現場のテストコードのコーディング規約づくり

10.2 QA 内容 QAテストの種類・形態を紹介。 コンポーネントテストユニットがどのように連携するかを調べる 機能テストユニットを機能ごとにまとめてEnd to End（端から端まで）のふるまいが完全かを調べる シナリオテストユーザーがシステムを使って、実際に使えるかを調べる パフォーマンステスト何百万ものアクセスに耐えうるか調べる セキュリティテストコードの脆弱性を探す プロジェクトに必要なテストはリスクによって異なる。たとえばペースメーカーとソーシャルメディアのアプリケーションではテストの方法は変える必要がある。Google、マイクロソフト、Amazonは品質担当はQAの自動テストを作れる人たちにして成果を上げている。 10.2.1 テスト駆動開発はQAの代わりではない ふるまいを「検証」ではなく「表す」方法としてテストファースト開発（TDD）を行うと、どんなテストが必要かがより明確に理解でき、無駄がなく意味のあるテストの土台が手に入る。これは安心してコードをきれいにするのに役立つ。 しかし、これ自体がQA作業を置き換えるわけではないと言っている。セキュリティ関連のテストをしなくてよいわけでもないし、パフォーマンス関連のテストをしなくてよいわけではない。 10.2.2 ユニットテストは万能ではない 基本的に、ユニットテストはテストファーストで作れば、良い設計の手助けとなる。 しかし、ユニットテストではなくEnd to Endテストで確認したいものもある。たとえば、UIとのやりとり、DBとのやりとり、マルチスレッド、高度なコード、などだが、これらはテスト駆動開発を使用せずに書かれていて、テストのないコードになっておりテストが困難な場合が多い。 設計を変更して構わないなら本質的にテストできない機能はないが、設計を変更できないときもある。（既存のコードとやり取りしている場合、既存のパッケージを使用している場合など。） そういうわけで、ユニットテストはテストファーストで進めば、良い設計の手助けとなるが、万能ではない。 学び テストの種類と目的の理解が深まった 自身のプロダクトはどんなテストが必要か、こういったテストの種類を知った上で考える必要がある テスト駆動開発はパフォーマンステスト、セキュリティテストなどのQAをするのは難しい。（費用対効果が薄い） テストファーストでユニットテストを作れば良い設計の手助けになる UI、DB、マルチスレッド、高度なコードなどはテストが難しい（観測が難しい） 学びを活かすアイディア・行動 テストコードの目的の事前知識整理 現場でのテストコードの運用範囲を決める。 テストコードのコーディング規約づくり（テスト運用の注意点）

10.1 テストと呼ばれるもの 内容 テスト駆動開発の話の前に、一般的なテストの種類と目的を理解しようという前置き。 10.1.1 受け入れテスト=顧客テスト 受け入れテスト、あるいは顧客テストはストーリーのふるまいを明確にするもの。受け入れ基準を定義することで、受け入れテストがどうなったら終わりになるか明確になる。それにより、 開発者が特定のエッジケースや例外のシナリオの理解に役立つ 開発者がどうなれば正解か理解しきれずに進めてしまい、作り過ぎてしまうことを防止する などの効果がある。これにより開発者は安心して進む事が出来る。受け入れテストツールにGherkinという自動化ツールがあることの紹介。受け入れテスト駆動開発に関する書籍2冊紹介。 Lean-Agile Acceptance Test-Driven-Development Specification by Example 10.1.2 ユニットテスト＝開発者によるテスト ユニットテストの概要が書いてある。 ストーリーよりも小さいテスト 開発者がテスト駆動開発で作るテストコードによるテスト ドキュメントとしても機能する 将来の変更時のミスを見つけるための回帰テストにもなる 10.1.3 それ以外のテスト＝QAテスト ワークフロー中のコンポーネント間の相互作用をテストする結合テストのように、QAプロセスの「一部」になる。結合テストは、モックではない実際の依存関係を使用してコンポーネント間の相互作用をテストする。そのためユニットテストより多くの依存関係をビルドするのでビルド時間がかかる。 機能をテストするために、ユーザーの入力をシミュレーションするツールを使うこともあるが、これがテストの唯一の方法なら、考慮すべき設計上の制約があるかもしれない。できるかどうかはさておき、簡単に検証できるようにテスト可能なコードを書くことを追求すべき。 テストを2つのカテゴリに分類するとする。 リリース候補を検証するために必要なテスト そのほかすべて これらはできるだけ多く自動化することが重要だが、リリース候補のテストをすべて自動化することはさらに重要。人間を介入させると、外部への依存性が生まれ、うまくいかないことがあるからだ。問題が起きる可能性を最小限にするために、できるだけ依存関係を少なくなるようにするが、ソフトウェア開発プロセスも依存関係を少なくすることが必要だ。GPSなどの機能は人間によるテストが必要なケースだが、そういう場合はコンポーネントを切り分けて必要なところだけを人間に任せる。 学び 受け入れテストはストーリーの振る舞いを明確にするものであり、これが要件である。 これを基準にテストの増えすぎや実装の増えすぎを抑えることができる。 テストスイートの意味。テストの集合。 上記「内容」 結合テストの定義について明確になった。モックではなく実際の依存関係を使い、コンポーネント間の相互作用をテストする。 問題を減らすためにソフトウェア開発プロセスにおける依存関係も減らす。 人間を介入させると外部への依存関係が増える。 学びを活かすアイディア・行動 テストコードの目的の前提知識整理 受け入れテスト自動化の学習 現場のテストコードのコーディング規約づくり

10.0 まずテストから書く 内容 テスト駆動開発（TDD）は死んでしまったと主張する人たちもいる。良いアイデアに見えるものの実際には多くのテストや、実装に依存するテストがかえって負担になってしまうという「テストによるダメージ」となりうまくいっていないという理由で。テストファースト開発を行う利点は、既存のコードを変更するときにサポートを得られることであるが、いつテストを書くのをやめるべきかわからないときに、不必要に多くのテストを書くことになったり、実装依存のテストを書くことになったりと、「テストによるダメージ」が発生する。こうなるとテストの変更が難しくなり、変更しやすさの手助けになるどころか負担となり、コードの変更は困難になり時間がかかるようになる。 しかし、テストを仕様と捉えることで、必要なテストが明確になる。 テスト駆動開発を正しく使用する方法と、落とし穴があることを伝えている。 学び テスト駆動開発を間違って行うと負担になる。正しく使うためには仕組みの理解が必要だ。 不必要に多くのテストや実装依存のテストは 学びを活かすアイディア・行動 テスト駆動開発のノウハウ整理 現場のテストコードのコーディング規約づくり