こちらはAutomateシリーズのパート３です。パート1『自動化の進め方』はこちらあります。パート2 『自動化テストのFlakiness（不安定性）をなくすには？』はこちらあります。
ある夏の夜心地よい眠りから一気に現実に引き戻される事象が発生。自動モニタリングシステムの「本番環境のABCシステムに問題発生」のアラートにすぐ飛び起きて手動で確認したところ、ABCシステムは特に問題なさそう。
調べたところ、誰かが修正を反映したために自動モニタリングシステム自体に何らかの不具合が発生しただけだと知り、拍子抜けしたことがあります。あなたも同じ経験がありませんか？
自動テストを扱うエンジニアなら誰でも「あるある」と頷いて頂ける話だと思います。ローカルで変更を行い、そこでは正常に動くのに、同じ変更をマージしてサーバーで実行すると問題が発生してしまうケースです。これを解決するための1番お勧めの方法は、テストのフレームワークに、継続的インテグレーション（CI）を実装することです。
The ✅ of clean code
最近のバージョン管理システムでは、実際に変更をマージする前に、変更に対してテストが実行されます。そこで是非皆さんに試してみて欲しいことがあります。もしもコードが別のコードをテストするだけのものである場合、もしくはテスト中のアプリケーション（AUT）に対してのみテストを実行する場合、ちょっと細かいですが、次の工夫を加えてみてはいかがでしょうか。
まずAUTの最も安定した部分を特定し、そこにCIテストの照準を当てます。そして、コードベースに何者かが変更をマージしようとした時に、CIテストを走らせます。テストがもし失敗したら、危険な変更のマージであるか、バグなどの理由でAUTが正常に動いていない、ということになります。どちらにしても、自動テストのエンジニアとしてはWIN-WINになります。
例：もしもAUTにログインページやホームページがある場合は、ページの読み込みをCIテストのターゲットに設定しましょう。
失敗もOK。ただ、いつも新しい失敗をするように！
PayPayでは、これらのチェックをしっかり行うことで、安眠を確保できるだけでなく、継続的テストフレームワークを全てのレベルで間違いなく実行することに繋がっています。レベルと言えば、エンドツーエンドのテストには複数のレベルがありますね。それについては、また来月ご紹介します。それまで、サヨナラ！