DX開発事業部の矢原です。
先日行われた開発生産性Conference 2024の2日目に参加してきました。
和田卓人さんによる「開発生産性の観点から考える自動テスト」というテーマの基調講演についてのブログです。
約40分の基調講演は非常に有益で、あっという間に時間が過ぎ、もっと聞いていたいと思うほどでした！！！
すべての内容を書きたいところですが、特に印象に残った部分についてお伝えします。
概要
『LeanとDevOpsの科学』出版以降、自動テストと開発生産性の関係はより明確になり、効果的な自動テストの姿も見えてきました。この講演では開発生産性の観点から改めて自動テストのあるべき像をまとめていきます。
基調講演の流れ
- なぜ自動テストを書くのかの問いに対する結論
- 自動テストを書く目的を細分化して説明
- 信頼性の高い
- 実行結果に
- 短い時間で到達する
- 状態を保つ
自動テストを導入する目的
信頼性の高い実行結果に短い時間で到達する状態を保つことで、開発者に根拠ある自信を与え、ソフトウェアの成長を持続可能にすること
講演の中で「テストは体重計のように、体脂肪や体重を測って、その情報をもとにもう少し体脂肪を落とすために〜をするといったアクションに繋げるためのもの」というようなこともお話しされていました。
信頼性の高い
テストの実行に嘘がないと信頼性が高いテストと言えるそうです。逆に実行結果が正しくないのにテスト結果が成功していたり、実行結果が正しいのにテストが失敗していたりするとテスト信頼性が下がってきます。
また、俗に言う何もしていないのに壊れたというものがテストケースの全体の1%でもあると、テストは価値を失い始めるとのことです。1%しかなくても価値が失われてしまうんですね。結構衝撃でした。
実行結果に
テストの実行結果を見て、デプロイ、マージ、コードの修正などを行動を促すような自動テストの実行結果でないといけないとお話しされていました。“信号機の役割”という表現もされていて、緑なら進め（デプロイ、マージ）ですし、赤なら止まれ（デプロイせずに失敗箇所を特定して修正）という行動に繋げられます。
テストが成功していれば、デプロイやマージが可能と判断でき、失敗している場合には「何が、どこで、どのように失敗したか」を絞り込めるテストコードを書く必要があり、その例をサンプルコードなどを使って紹介されていました。
短い時間で到達する
テストは大きく、ユニットテスト・インテグレーションテスト・E2Eテストの3つに分けられます。
一般的にその中で一番実行時間が短いのがユニットテストです。
会場で「データベースにアクセスするのはユニットテスト？」というようなユニットテストに関する質問がいくつかあり、会場の人だけでもユニットテストに関する解釈がバラバラでした。ユニットテストにはロンドン派やデロイト派などの宗派があり、そもそも人によって解釈が違うので、テストサイズという基準に置き換えると解釈のブレを少なくできるとおっしゃっていました。
今までユニットテストってどこまでが定義なのだろうと悩んでいたので、この話を聞いた時に感動しました。
状態を保つ
テストピラミッドのバランスを最適に保ち、アイスクリームコーンアンチパターンにならないようにしましょうとのことです。
世に出ているテストピラミッドは、一番下からユニットテスト、インテグレーションテスト、E2Eテストですが先ほどのテストサイズに置き換えると以下のようなピラミッドになります。
また、技術レポート（Technology Reader）において、E2Eテストの過剰投資はするなという位置付け（HOLD）にレーティングされているそうです。
スモールサイズのテストを増やし、早期に失敗に気づくことが重要で、スモールサイズのテストが失敗していたら該当箇所の修正をする必要があるので、その後のミディアムサイズ以上のテストは実行する必要はないとのことです。
（個人的に下記の画像のようなワークフローを見るとテンションが上がるので、このワークフローを見た時には心の中で盛り上がっていました）
感想
自動テストを導入する目的を見失わないことが大事だと感じました。生成AIが流行し、変化のスピードが早まる中で、その変化を支えるためにも自動テストの重要性は増していると感じました。
いちエンジニアとして、開発生産性を高めるためにどうすれば良いかを常に考え、日々の業務を全うして高い価値を提供できるように努めていきたいと強く思いました。この基調講演で引用されていた書籍『LeanとDevOpsの科学』と『Googleのソフトウェアエンジニアリング』を読んでみようと思います！
