価値のある単体テストを書こう

https://qiita.com/advent-calendar/2023/ne
こんにちはー！
NE Advent Calendar 2023の11日目、ゾロ目の日担当のはやしまき（@_mkmk884）です🦒
22日目も書くのでぜひ読んでください😉

みなさま、価値のある単体テストを書いておりますでしょうか？
私はなんとなくでテストを書いていた過去があります。。

先日、「単体テストの考え方/使い方」を読んで、価値のある単体テストを書かなきゃなと心から感じたため、今日はその本の紹介をしようと思います！

「単体テストの考え方/使い方」の概要

https://www.amazon.co.jp/dp/4839981728

内容は以下の4部で構成されています。

• 第1部：単体（unit）テストとは？
• 第2部：単体テストとその価値
• 第3部：統合（integration）テスト
• 第4部：単体テストのアンチ・パターン

単体テストの定義や書き方・構成要素、モックとスタブの違い等の単体テスト自体のHow寄りの話だけではなく、なぜテストコードを書くのか等の考え方の話や、テストをより価値のあるものにするためのプロダクションコードのリファクタリングについても書かれています🤩

特に刺さった部分やそこから得たこと

取るに足らないテスト、壊れやすいテスト

• 取るに足らないテストは、プロダクション・コードと同じことを別の書き方で表現しているだけで常に成功する意味のないテスト
• 壊れやすいテストは、whatではなくhowをテストしているため、リファクタリングへの耐性が低い

読んだとき、ドキッとしました。
1年目の見様見真似でテスト・コードを書いていたときは、何を確認するテストにすればいいのかよくわかっておらず、とりあえず通るテスト・コードを生み出してしまった自覚があります。。

該当するテスト・コードになりそうなときは、本当に確認する価値があるテストなのか、テスト対象のプロダクション・コードの依存が複雑すぎることでリファクタリングを検討するべきであるかどうか、しっかり見極める必要があることを学びました👀

モックにするのは管理下にない依存のみ

• データベース等の管理下にある依存はモックを使わない
• メールサービス等の管理下にない依存はモックを使う

単体テストの導入やカバレッジ向上のためにモックが多く使われているテスト・コードを見たことがあります。
私も「単体」という言葉に囚われていたので、今テスト対象としているメソッド自体が正しく終わることしか考えていなかったんだなと反省をしました。

この本を読んで、何をテスト対象として、それを検証するためにはどこまでを実行すればよいのかを考えた上で正しくモックを用いるべきだなと学びました。

質の悪いテスト・ケースを作成するくらいならテスト・ケースを作成しない方がまだまし

• 質の悪いテスト・ケース（明確な価値をもたらさないテスト・ケース）を作成するくらいなら、テスト・ケースを作成しない方がまだまし

いや、それだ。それな。それはそう。

テスト・コード書かなきゃ〜、書くと品質が保たれるよね〜と思いながら、カバレッジが満たされるテスト・コードを書いていると価値のないテスト・コードがどんどん生み出されていたりします。
とりあえず通るものを作ってしまうと、壊れているのに正しく検知できないテスト・コードが生まれてしまうよなと認識しました。何と言っても、時間も浪費してしまいますよね。。
これが明示的にかかれているのがいいなと思いました！

まとめ

よく技術書で「コードは負債」と書かれておりますが、テスト・コードも同じ。
（生業としてる身としては悲しいですが……）

であれば、なおさら価値のあるものを生み出していかないといけないよね、ということを感じた1冊でした😌

（余談）わたしの読み方

めちゃくちゃ単純なことだと思いますが、この本を読むときに意識した読み方を書きます🖊

私はこの本をチームメンバー全員で輪読会形式で読んでいました。
（前半：みんなで同じ範囲を読む、後半：印象に残ったことや感想を共有する）

翻訳本ということもあってか、正直、難しくて頭に入ってきづらいなーと思いながら読んでおり、輪読会のときに焦りを感じていました😖

途中から私は以下2つのことをすることで、本の内容理解がスムーズになりました！

• 各章のまとめから読むようにした
• 自分で先んじて約6割理解目標で読んでおき、輪読会を2周目に読む機会とした

本難しいな〜と思っているアナタ！
本を読む際に誰かを巻き込んで、軽くでも1章ずつ2周してみるのオススメです〜！