TDD の話②

こちらの講演会の内容もよかったです！
前回の TDD の話 と内容が似ている部分も多いので、個人的に学びになった部分をピックアップします。

ネタ元

• 【DXD2024】望ましい自動テストとは：どのようなテストが開発生産性と開発者体験を共に高めるのか
  スピーカー：t-wada さんこと 和田卓人さん

テストサイズの話

引用元「Google ソフトウェアエンジニアリング」

テストサイズ

• Small
• Medium
• Large

Small Test の定義

テストの実行が１つのプロセスに収まっているもの

Medium Test の定義

１つのプロセスには収まっていないが、１つのマシンに収まっているもの

Large Test の定義

１つのマシンに収まっていないもの

Test Scope と Test Size

一周回ってピラミッド型

ピラミッド型は古いよねって議論もあり、トロフィー型とかハニカム型がいいんじゃない？って話もあるけど、ユニットテストやインテグレーションテストの解釈がそもそもブレてるよね・・・

テストサイズで話をすると、ピラミッド型に戻って来る

テストサイズを下げるには

Large から Medium へ

テストダブルを使う。
偽陽性、偽陰性を招きやすいので使い方には注意が必要。

１つのマシンに収まらないテストを１つのマシンに収めるためには、偽物を作る。
例：DynamoDB なら DynamoDB local などを使う

Medium から Small へ

テストしにくいところを薄く切り離して、テストしたいところを大きく露出させることで、１プロセスの中にテストを収める。
テストしたいところを、入出力などから切り離すことによって、１プロセスにテストが収まるようにする。
関数プログラミングだと副作用の分離という。
低結合高凝集の設計をしていくとテストサイズが下げやすくなる。
端的に言うと「良い設計をしましょう」

良いテスト

変化を支えるテスト。

様々なレベルで、様々なスコープで変化を支える。

まとめ

ピラミッドはテストサイズで構成しましょう。
テストダブルを使ってテストサイズを下げましょう。
信頼性の高い実行結果に、短い時間で到達する状態を、長期的に維持するようなテスト戦略を立てていきましょう。

おわりに

テストサイズの話を聞いていたら、デトロイト派とかロンドン派とか、なんかどうでもよくなってきました😇
「ロンドン派だからこう書かなきゃ・・・」とかじゃなくて、「どういうテストを書くと変化を支えることができるテストになるのか」のほうが大事なのかなと。

公演の中で何冊かの本から引用して話をしていたのも印象的だった。手を動かしてコーディングするのと同等に本から学ぶことも多いということだろう。読むのは苦手だけど、公演の中で紹介されていた本は読んでみようかな。(和訳のある本だけですが・・・)