SeleniumConferenceで一番感動した講演についてのメモを公開します。
いろいろ理解がおいつかなかったり間違ってたりするものもあるかもしれません。
背景とか
テストと言えばピラミッドの形、System,Integration,Unit件数がUnitが多い。
実行時間で考えるとSystemレベルが大きい。逆ピラミッド。
並行して実行すべき・継続的にやるべき。自動化されたテストが必ずやるべき。
Systemレベルのテストが終わるまでにこのくらいかかるから。
Systemレベルのテストを並列化すればいい。それも分けてる。バッチ。
（すごい。）
かなりのリソースに分けてやっても、４５分もかかる。７万くらいのテストをやってる。
いいと思われるかもしれませんが、少しでもビジネスに早くするため１分でも短縮したい。
今まで
マスターブランチのテストだけを考えていた。
フィーチャーブランチもある作ってやらなければいけない。
時間だけでなくお金の問題もある。デプロイ時間、４０台並列、担当しているアプリもいっぱい。
７０のプルリクを毎日毎日変更のテストしなければいけない。
１５０００のテストブランチをかけている。
ものすごくコストかかっている。
ピラミッドの形を変えよう！
db Unitテストを補完するものを作るしようとしている。
コンポーネントテスト、JavaでかいたものがSQLでどのように実行されているかなど。
本題
TestImpactAnalysisをし、どんな利益が得られたかを話します。
Clover、Codeカバレッジレポート等テストに関する知見が得られる。
ユニットテストだけでなくいろいろできる。
すべてのコミットの中の変更ファイルを見て、関連するテストはどれかを抜き出す。どのテストなのか？
マッピングすることにした。
関係あるテストだけを抜き出し、関係あるテストのサブセットだけを抜き出す。
Jacocoの問題は、作成できるのがCodeカバレッジ詳細が教えてくれないと思っていたけど、Javaバイナリ、・クラスファイルを利用して、CSVファイルに出力することで、Jacocoでできることがわかった。
・アプリケーションをjacocoエージェントにつなげる
・テストを実行し、エグゼファイルを作る。すべてのテストにCodeカバレッジ情報をCSVファイルを出力。
それをもとに、timmyというテストインパクトのデータベースを作った。
timmyデータベース
・どのテストがどのJavaファイルの変更に結びついているデータベース
フィーチャーブランチに変更をマージしたとき、
変更したファイルを、timmyに問い合わせ、最小限のテストを実行する。
デリバリー
みんながCIを触っていて、パイプラインにプッシュ、
究極の受け入れ試験。最小限必要なテストセット。
それが現実的にうまくいくのか？検証の必要があった。
本当に導入できる？のお試しを行った。
シャドーブランチをもう１個つくる。フィーチャーブランチに
timmyにどんなテストが必要か聞いて？１ヶ月くらい実験した。
実際に使えることが証明できた。
評価
新しいサービスでは、99.99%アベイラビリティ、レスポンス
満たしていることを示すため、ダッシュボードを作成して、
DBの利用状況・メモリ利用率がわかるようになっている。
「観察できる」ができる。
継続的にサービスが動いていて、timmyに対して200msいないに帰ってくることを確認する。
ここまでうまくいって、ハッピーです。
最終的に改善できたのか？
テスト影響分析をしたのが、良い効果を発揮できたか？
４５分かかるテストが３０分でできるようになった。
十分自身が持てるようになったらmasterブランチで使うかも。
ROI
４人で1ヶ月くらいサービスを作った、文書も作った、教育した。
わずか１ヶ月で投資を回収できた。
次のステップ
どんな変更にも使えるのか？
依存性が変わったり、いろんんな変化がある場合にどういう風に
テストを選ぶことができるのか？
Javaファイル以外(xmlとかmvnとか）のファイルが変わった場合についてどうすればいいかわかっていない。
timmyに入っていない場合、このテストで十分と言えない。
場合によってはすべてのテストを全部実行している。
過去２週間でどのくらいの変化があったか？何度Ciコミットがあるか？それのテストをやらなければいけないか？の頻度を確認して、価値があるか判断できる。
jacocoはCodeファイルを実行するものなので、jsやhtmlの変更に対応できていない。
jsやhtmlの場合にも、どういったテストをするのか、どうやって改善するかを考えると、
html,js, Seleniumテストに入れるとかになる。
インタラクションをdumpしたり、そういった情報をtimmyにプッシュすればいいかも。
まとめ
・自動化テストの成長計画を考えてください
どれが価値があるテストか？抽出する術を考えなければいけない時期が来る
・TestImpactAnalysysは自動テストの実行時間を削減する
・テストインパクトアナリシスをできるツールとして、Cloverが使えるかも。
・パイプラインを改善することにより、エンドユーザの満足につながる
ここでも話すよ
AgileAutomation Days
October 2019 28-29
他の事例とか
重複していたテストがあった場合は、省いてもいいかは考えている。
すべてのテストを実行するべきではない。
すべてのアーキテクチャは構造化されているから。通信をしたりしている場所などうまくアーキテクチャされているが、そうでないものもあるかもしれない。
Microsoftがうまくいっているよという論文を出している、Facebookでもうまくいっているよ