14章 大規模テスト
14.1 大規模テストとは何か
では何故、大規模テストを設けるのか
似た話ではあるものの、全く言及されないのはちょっと不思議
エンジニアリングの話にしぼりたかったのでは?
環境、データ、検証方法、実行時間
APIに新バージョンがあるとしたらどうだろうか
外部APIの呼び出しはCIでは(大量リクエストを避けるため)モックする場合が多いので、これ起因の障害になることがたまにある
これが原因で減らしていくことになる
メンテナンスの日時とかを把握しておかないといけないので、運用が大変
APIがメンテされててもドキュメントがメンテされないケースがある
モックは陳腐化する
オッカムの剃刀はテストコードにおいては正しくない場合があるのかも
下手に最小限の機能を備えたテストダブルを使うより、余計な機能がついた本物のオブジェクトを使ったほうが良い
モックを追従させるのは気付きにくくて大変
14.2 Googleの大規模テスト
連鎖テストのような考え方をサポートするツールって意外とないんだよなーっていうのを感じている。チープな実装としてはグローバル変数でいい感じにするってやっていたんだけど、ドキュメント型DBをつかえばここにおけるデータリポジトリーを簡易に実現できるしよさそうだなー。MongoDBかDynamoDBを実装に使ったこういったテスティングフレームワークの拡張があってもよさそうにおもった。
連鎖テスト: システムやメソッドの結果を利用した連結
ドミノが倒れるか
単体テストの結果などは破棄されることが多いが、これらを利用してインテグレーションテストを構築していく
長いシステムテストを網羅的に作るのは同じことを何回も書かないといけなくてしんどい
テスト実行後の状態をJSONなどスキーマレスな形態で記述する
後ろのテストはそのJSONを読み込んで実行する
UNIXパイプラインに発想が似ている?
こんなやつを書いていました。
given1 |> test1 |> test2
given2 |> test1 |> test3
TestData test1(TestData data) {}
class TestData {
List<String> title
List<TestResult> results
Map testContext
}
14.3 大テストの構造
Rickroll
「またお前は騙されてダム板へ飛ばされてきたわけだが」
海外にもあるんすね……
このへんの話笑えるようにしておくの本当に大事ですね><
サードパーティのシステムにはテスト用の公開共有環境がない場合があり
外部APIから返ってくるデータ依存の処理は絶対にテストできない、というジレンマがここで生まれる
外部APIで返ってくるデータに依存した処理は書かないほうが良い
けどエッジケースがどうしても出るので、依存するAPIの数自体をできるだけ小さく抑えたい
この少しあとの「14.3.1.3 記録/再生の代理機能」が解答編のようになっているが、大規模テストの実績をもとにする以上はやっぱり本物のデータは使えない
運用が始まっているなら、本番環境のトラフィックを記録してテストに使うのが良いアイデアのように思える
14.4 大規模テストの類型
この節はリファレンスだと捉えれば良さそう(長い)
いくらGoogleでも全てのレベルのテストを全てのシステムに対して行っているとはとても思えない
逆に、どの類型をいつ選ぶか、という話題はあっても良かった
SUT/データ/アサーションへのアプローチの組み合わせなのでこの数にはなる
Googleのチームは現在、Catazillaという内製システムを用いて毎週何千ものカオステストを実施している。
凄いー
儲かってるシステムにしかできない
完全な成熟期で、障害による機会損失が一番怖い場合にこうなる
ほとんど自動復旧じゃないとこの数は無理
「なんかおかしいな?」でリロードすると直ってるのってもしかしてこれ?
手で直さないといけないエッジケースを洗い出してどんどん強くしている
14.5 大テストと開発者ワークフロー
大規模テストには、ドキュメントに記載されたオーナーが存在しなければならない
この誰かがオーナーっていう考え方はここまで読んでGoogleのルールとして明確にありそうだ
まったく同じことを思いました。オーナーシップをいろんなところで考えている。
組織的な成果物(ドキュメント、コード)にはオーナーを置いている
9.2のラストに「オーナーシップ」についてのコラムあり
Googleでは、知識と責任のセットをオーナーシップと呼び、知識を行使し責任を果たす者をオーナーと呼ぶ
プロセスはどうだろう?
「なるべく自動化」の話のほうがよく出てくる
知識はドキュメント化されるが、ペアプロみたいな伝達の手段を取ることもありそう
プロセスの設計と運用に責任を持つ人はオーナーというよりマネージャーっぽい
こういう運用するからGoogleはいっぱい人が必要なのかも
ボトムアップ的なものへの信仰って薄れましたよね
14.6 結論
14.7 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
インフラも自分達で整えられるからかな?
テストの文化が少なくとも当社にはちゃんと育ってないように感じる。step数当たりの件数満たしていたら大丈夫的な考えが中心なので、そもそも品質とは何かやSQuBOKの話をすると思考が停止する。
障害発生が最大の機会損失になるほどビジネスモデルが成熟している
普通は市場にキャッチアップするのを優先したほうが儲かる
現場でどこまでできているか?
sleepまわりのユーザーをエミュレーションした待ち時間とかはやれたりやれなかったり?A/Bテストやカオスエンジニアリングまわりはまだできていないなー。それ以外はなんらかの形でやったことあるかな。
本番環境のコンテナ化がやっと視野に入り始めているので、実現すればカオスエンジニアリングのハードルが下がりそう
システムテストの自動化とUATくらいが精々。パフォーマンスのテストは本番クローンの開発サーバを用意して皆で使うことでなんとかしている
この本があるのになぜ実践する企業はすくないのか?
サブシステムごとにテストに強い人が必要になりそうだけど、実際にはサーバーアプリケーションエンジニアにしかいないとかありそう。
テストの類型を細かく切り分けられるほど文化が成熟しておらず、人手と時間が足りていない
そもそも大規模インフラが必要だったり世界有数のアクセスを捌いたり複数の外部システムを組み合わせたりするシステムを持っていない
それの乗り越え方はなにか?
大規模な自動テストを踏まえたテスト戦略と投資に時間を使うことに経営がコミットするとか?
Googleのテスト戦略がここまで来た歴史とか経緯が知りたい
Google検索、10年に数分ほどしか落ちてないのでは
ステップを小さくするとしたらどうできそうか?
現状の品質レベルによって起きている機会損失額と、大規模テストの実践によって低減できる金額を試算してみるとか?
投資対効果の考え方は必要だと思うので、この規模/このフェーズのプロダクトはこのレベルのテストみたいな相場感を考えたい