「開発生産性の観点から考える自動テスト」を拝聴して

発表

「開発生産性の観点から考える自動テスト」：和田卓人 さん（X）

講演資料はこちら

気づいたこと

• 前半部分はどこかで聞いた話を復習している感覚でしたが、改めて目的をちゃんと意識してテストコードをかけているか再確認する良い内容でした。
• 偽陽性と偽陰性の話も再認識した内容でしたが、最近直面したCITestの不具合などがこれにあたり対策の方向性の確認をしたり、また偽陰性の自作自演については、対象となるコードのロジックがテストコード側にも侵食してしまっている状態をたまに見かけたり、やってしまったりしていて、テストコードを後から書く場合に陥りがちなパターンだと、最近書いたテストをふりかえりと思いました。
• ユニットテストとテストサイズの話では、これまでユニットテストはテストコードで書き、結合テスト以上は、手動テストorE2Eテストで書くものだとふんわりとしたイメージをもっていましたが、そのイメージが壊され、テスト対象ごとに考えていく必要があると再認識することができました。
• モックを使うのか、実物を使うのかの話について、最近、AIを使ってモックを多用したテストコード量産していた際にあまり意味のあるテストをかけてない意識があったのですが、テストコードの目的をちゃんと考えテスト対象ごとに、変更しやすいテストにしていく必要があると再認識できました。

メモしたこと

（画像はスライドより抜粋）

自動テストは生産性のエンジン

• 自動テストをコスト削減を目的に導入するとアンチパターンです

• 導入コスト、学習コストが嵩み、狙い通りにはいかない

• システム開発ではアジリティが大事

• アジリティとは世の中の変化についていくスピードのこと

• 自動テストは現状を固定するものではなく、変化を可能とするためにあるもの
  

• 自動テストは信頼性の高い状態に保たなければならない

• テスト全体の1%に不具合があると信頼が損なわれる（Google本）
  

-　信頼を損ねる2つの状態 偽陽性と偽陰性

テストの実行結果は「情報」

-　信号機
-　失敗は２種類ある 例外とアサーション失敗
-　問題の特定「どこで、なにが、どのように」

ユニットテストの定義がバラバラ

-　代わりに「テストサイズ」という考えを使うと良い

スライド内の参照書籍

さいごに

• オフラインでのエンジニア系イベントは初参加でした。
• オフラインだからこそ、発表者のプレゼンスキルの高さなどを体感することできました。
• 熱量のインプット量もオフラインの方が多かったので、足を運んで参加する価値があったと感じました。

以上です。