Googleのエンジニアリング文化が分かる凄い本です。
GAFAの一角であるGoogleのエンジニアリング文化を知ることで、
「あなたの仕事に対する意識が上がる」
「あなたのエンジニアリングの基準を高める」
ことができるのが最大の価値ではないかと思います。
5章 チームリーダー入門
Googleではマネージャー＝人員を管理する人、テックリード＝技術的取り組みを手動する人である。
マネージャーやテックリードのためのアンチパターンと建設的パターンが紹介されている。
良いマネージャ
伝統的なマネージャーは物事をやり遂げる方法を気にする一方で、優れたマネージャーはどんな物事がやり遂げられるのかを気にする（そして、やる方法を見つけるのはチームに任せる。）
11章 テスト概観
なぜ自動テストを書くのか
Googleのエンジニアリング文化に自動テストはしっかり組み込まれているとのこと。
Googleでは、なぜ自動テストを書くのかが記述されている。
・バグを捕捉すること
・変更を可能とする能力を備えておくため
である。
Googleも最初は自動テストがなかったが、サービスが大きくなるにつれて、チームメンバーは変更を加える際に問題がない（デグレがない）と言う確信が持てなくなってきた。
本番で障害が起きて初めて問題を知ると言うことがあった。
その問題に対処するため、自動テストが導入されたのがきっかけ。
テストコードのメリット
- デバッグの減少
- 変更への信頼の増大
- ドキュメンテーションの改善
- 変更によってテストがエラーになることは、その箇所のドキュメント修正が必要であることがわかる。
- レビューの単純化
- レビュアーは存在しうる条件を頭の中で追うのではなく、条件が自動テストによって記述されていることを確認すれば良い。
- 思慮に富む設計
- テスト可能にするために、モジュール化する、密結合を避けると言った設計が必要となる。
- 高速で高品質なリリース
- 毎日新バージョンをリリースしている。それは自動テスト抜きでは不可能。
NOTE:自動テストを最初に書くと言うことは、答えを知っている状態で問題を解く（＝コーディングする）ことであるというイメージを私は持った。テスト範囲
3つのテスト範囲を規定している。
| 狭い範囲のテスト | 個別のクラスやメソッドを対象とする。 | ユニットテスト |
| 中範囲のテスト | 少数のコンポーネント間の相互作用を検証する。サーバーとデータベース間など。 | インテグレーションテスト |
| 大範囲のテスト | － | 機能テスト／エンドツーエンドテスト／システムテスト／ファンクショナルテスト |
Googleでは狭い範囲のテストを書くことが推奨されている。
第12章 ユニットテスト
Googleではユニットテストとは、単一のクラスまたはメソッドのように狭い範囲のテストを指す。
Googleではテストコードの保守性を重要視している。
- 脆くないこと
- 無関係な変更に反応してエラーとならないこと。
- 明確であること
- テスト失敗後に、間違っている点、修正方法、そのテストがそもそも何をしているかがすぐにわかること
これが保守性の高いコードである。
理想のテストコードは、要件・仕様が変更されない限り、変化しないテストコードである。
保守性の高いコードを書くための重要なプラクティスが、
テスト対象システムのユーザーが呼び出すのと同じ方法でシステムを呼び出すこと。＝システムの公開APIに対して呼び出しを行うこと。
例えば、
狭い範囲、例えば単一テストのクラスであれば、publicメソッドをテストメソッドがから呼び出すこと。（privateメソッドはpublicメソッド経由で呼び出す）
広い範囲、APIのテストであれば、APIをコールする形でテストメソッドから呼び出すこと。（コントローラーをインスタンス化して実行ではなく、APIとして動作させて呼び出す）
これが重要とのこと。
挙動をテストする
テストコードは次のパートからなる。
・〜という前提条件のもとで（given）
・〜の場合（when）
・その場合は〜（then）
テストメソッドの名称は非常に重要。
テスト対象メソッドがシステムに対して行う動作＋期待する結果を表す名称が良い。
↓↓↓今回レビューした書籍はこちら↓↓↓
