# タイトルコール ようこそ、世界が広がるソフトウェア品質で。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 テストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 📢明後日1/29水20時からは生放送です！🍺 本編に入る前に一つだけ告知をさせてください。 いよいよ明後日、1月29日水曜日の20時からはVoicyの生放送を配信予定です。 ゲストにはマークさんをお呼びして、英語での情報収集、インプット、本の探し方などをお聞きしようかなと思っております。 ぜひビール片手にお聞きに来てください。 # 単体テストの考え方/使い方　第1部 はい、ということで本編です。こんにちは、経営人やなさみです。今回は単体テストの考え方、使い方という本を読んで今考えたことって言うんですかね。 印象に残ったこととか、なるほどなと思ったことをお話ししようと思ってます。 きっかけはですね、去年社内の臨時会でこの単体テストの考え方、使い方の本を読みまして 結構自分にとっては情報型と言いますか、知らないことがいっぱい書いてあったというのもあって、復習したいなと思ったのがきっかけです。 なんでこの本を読もうと思ったか、もちろん臨時会というきっかけはあったんですけど、自分の中でこの本を読む目的というのを今、パラパラ本をめくりながら思い出しまして、 単体テストというのはこれまで自分があまり関わってこなかった部分、よくわかんない部分だったので、一体印象テストということはどういうところが難しくて、 何を基本的にはこういうことを考えるべきだ、考慮すべきだ、基本ルールみたいなところを知りたいなと思ったのが一つ。 もう一つ目的があって、二つ目の目的は単体テスト、インテグレーションテストと統合テストかな、システムテストかな、 その三つのテストレベルの境目っていうのは何なんだろうというところをすごい最近、まあもやもやしているので、 その何か考えるヒントになるかなと思って、この本を読もうと思いました。 前置きはこのくらいにしましてですね、今ちょっと付箋を貼っているところをベースでいくつかお話ししようかなと思って見てるんですけど、 付箋多分40個ぐらいあるので全部はちょっと見えないので、第一章の方からパラパラお話ししていこうかなと思います。 そうですね、テストコード、プロダクションのコードとテストコードの割合がだいたい一対一から一対三になるということで、 プロダクションコードよりもテストコードの方が圧倒的に多くなるっていうのは、確かにそうだよな、そうだろうなというふうに思ってます。 確かになと思って付箋が入っているポイントでした。 あとはですね、これかな、一個印象的だったのは、コードは試算ではなく付箋というワードが結構、そうなんだっていう、自分にとってはちょっと新しい観点で、 プロダクションコードにしてもテストコードにしても、多ければ多いほどソフトウェアにバグが持ち込まれる経路が増えるっていうことで、 維持する保守のメンテナンスコストもかかるっていうところなんで、コードは試算ではなく付箋というような考え方をしているというのが、 そういう考え方もあるんだっていうのが一つ新しい、私にとっては新しい視点でした。 で、今まず一章のところ、第一章見て、なぜ単体テストを行うのかっていうところを見てるんですけど、 あとはよく聞く話ですね、カバレッジ・モーラ率の結果に縛られるっていうのはダメですよっていうのが書いてあって、 あくまでカバレッジっていうのはテストが十分に行われていないことを示すものであるということです。 なのでカバレッジがいくら高くても、高いから品質がいいわけじゃなくて、一定程度、この本の中で数値だったかな、 一般よく聞くのって80%とか、C0のカバレッジ80%ぐらいあれば、品質が悪くないよね、めちゃくちゃ悪くないよねってことが言えるだけで、 テストが十分かどうかっていうことは示せない、カバレッジでは表現できないっていうのはよく聞く話だったりはします。 他にですね、なるほどなと思ったのが、コードの中で特に重要な部分のみがテスト対象となっているっていうのがユニットテストとして大事なんだよってことが書いてあって、 確かになというふうに思いました。ロジックを含む部分なので、本の中ではドメインモデルという表現をしています。 2章に入ると、単体テストにおける2つの学派ということで、古典学派とロンドン学派の説明が書いてあります。 結構ここ、わかるようでわかんないようで、なんとなくわかったみたいな感じなんですけど、 ロンドン学派は、一体のコードをクラスごとに他の単体から隔離すべきという考え方なので、 テストしたいクラス、コードの単位、一体のコード、それ以外は全部テストダブルに置き換えましょうという考え方。 古典学派は単体というものを何かと捉えていると、振る舞い、一体の振る舞い、振る舞いの塊を単体というふうに捉えているので、 その一塊の振る舞いの外側にあるものは、テストダブルに置き換えるというような違いなのかなというふうに理解しています。 インテグレーションテストと、さっき間違えて統合と言っちゃったんですけど、本の中では言いついテストと書いてますね。 単体の考え方が2つの学派で異なっているので、当然インテグレーション、何と何を統合させるのかというところも結構解釈が変わってくるんだよなというのが本には書いてあって、 ますます単体テスト、統合テスト、そして言いついテストの境目がわからなくなったというか、明確なきれいな決まり、境界線というのはないんだなというのを改めてわかりました。 もう一つですね、よく見るテストピラミッドって一番下の多い部分がユニットテスト、真ん中がインテグレーションテスト、一番上の小さい部分がエンドとエンドと言われている感じではあるんですけど、 本の中で印象的だったのが、インテグレーションテストの一種としてのエンドとエンドテストというふうに書いてあって、インテグレーションテストというのは単体と単体をくっつけて統合してテストをやるので、外部プロセス外依存というのを1個か2個か使うというふうに本の中では書いてあります。 一方でインツイテストの場合は、ほとんど全ての繋がり、機能と機能の繋がりというか、ユニットとユニットの繋がりというものが、ほぼほぼプロセス外依存を扱っていますよみたいな説明がされているので、本の中ではインツイテストというのはインテグレーションテストの一種とも言えるというような表現がされていました。 本を読む前はインテグレーションテストとインツイテストの境目がよくわからないと思っていたんですけど、本を読んでみて、なるほどなと言いますか、インテグレーションテストとインツイテストってテストの区切り方が違うから明確な境界線を作るのがそもそも難しいというか間違っているのかもなという理解にアップデート、考えにアップデートされました。 インツイテストもユニットとユニットとユニットとたくさんのユニットをくっつけてエンドから触るというテストなので、それってインテグレーションテストの一部でもあるというのは確かにその通りだなというふうに思います。 そもそもなんでユニットテスト、インテグレーションテスト、インツイテストの境目を知りたいかというか考えたいか、理解したいかと思った背景というのが自動テストですよね。それぞれの自動テストでどこまでをカバーすべきなのかみたいなところを考えている中で、境目がよくわからないというのが私の課題意識だったんですけど、 この後の本の中でもこの後確か時間、テストの実行時間のところでインツイテストは時間がかかるからなるべく少量にしましょうみたいな話は出てきていて、何が言いたいかというと、自動テストの区切り方という意味ではユニットテスト、インテグレーションテスト、インツイテストという区切り方があまり良くないんだろうな。 という風な印象を今のところ持っていて、確かGoogleかな、どっかのウェブサイトにも書いてあったんですけど、自動テストの区切り方を時間、スモールとミディアムとナージ、テストと分けていたのをどっか見た記憶があるんですけど、 そういう風に時間がかからないテストを中古ライデマ、外部依存のプロセス、外部プロセスとかにアクセスしたりする、データベースとかにアクセスするから多少時間かかるミディアムと、エンドツーエンド、エンドツーエンドという言葉を使わないと良くないですね。 時間がかかるテストの実行に時間がかかる裏地のテストという風に分けているという記事を読んだので、確かにそういう風にテストの実行の時間がどのくらいかかるかという基準で自動テストを分けるという考え方もとても良さそうだなという風に感じました。 第3章では単体テストの基本ということが書かれていて、AAAアレンジアクトアサートの形で書くと良いですよ、分かりやすくなりますよという話だったりとか、あと一つのユニットテストで確認することは一つにしましょうねとか、 テストケースの名前かな、他はプロダクションコーダーが解決しようとしているストーリーについて分かるようにしましょうというようなことが書いてありました。 ここら辺は自分が単体テストを書いたことがないんですけど、こういうことを気をつけなきゃいけないんだな、ふむふむという風に読んでおりました。 # 単体テストの考え方/使い方　第2部〜第4部 はい、ここから第2部に入るんですけれど、第2部以降は結構今いろんなことが書いてありますが、印象的だったのが良い単体テストの構成要素みたいなところですかね。 要素があって、3つかな。対抗に対する保護、リグレッションですね。リグレッションに対する保護、リファクタリングへの耐性。 あともう一個なんだっけ。迅速なフィードバックということで、良いユニットテストはこの3つの要素があって、みたいな話、具体例とかがあって、まあそうだよな、確かになというか、 なんとなく理解していたことがきちんと言語化されて、自分の中でもイメージ、図として理解を深めることができたな、みたいなのを感じています。 ぶっちゃけちゃうんですけど、結構私がこの本を読んだ目的っていうのが、単体テストの基本を何を気にしなきゃいけないかっていうところを理解するのと、 あとインテグレーションテスト5テストの3回目っていうところで、結構すでに第1部を読んだところで、お腹いっぱいと言いますか、満足をしてました。 なので、輪読会とかでももちろん事前に読む部分はちゃんと読んでいたし、分からない箇所は輪読会でちょっと質問してみたりっていうこともしてたんですけど、 基本的にはこの本でどういうことが書かれているのかっていうところの概要だけ、また今後分からなくなったら、あれそういえばこの本に書いてあったなっていうことが思い出せる程度に理解をしていったりしてました。 印象的だったのは、観察不可能な振る舞い、オブザーバブルビヘイビアと、あと実装の詳細っていうところを分けて考えましょうみたいなところですかね。 テストをするのはあくまでテスト対象は振る舞いであって、実装の中身をそのままテストコードとして書いたら意味がないよねみたいなことが確か書いてあったかなと記憶をしています。 あとはですね、単体テストの手法を紹介していて、それとあと良い単体テストの要素を3つあったと思うんですけど、そのうちの2つがトレードオフになっているので、 どういう時にどの手法を選ぶのかっていうのは何を大事にしたいか、何を確認したいか担保したいかみたいなところ次第で変わってくるんだろうなみたいなのを何となく、すごくぼんやりと理解をしたという感じです。 全体的にですね、図での説明がすごく理解を深めるのに助かったなというのも印象的でして、結構私自身が物事を理解する、把握する時っていうのが視覚的に理解するというか視覚的な情報からインプットした方が文字よりかは理解しやすいという性質が自分はあるのかなと思っているので、 そういう意味でもですね、たくさん図があって説明が補足してくれるというのはとても助かりました。 あとはですね、循環的複雑度、サイクロマティックコンプレキシティの話がちらっとコラムで書いてあって、 こう読んだ時、そういえば一個思い出したことがあって、前職でですね、このサイクロマティックコンプレキシティの英語の論文を読んで、それをチーム内で発表するみたいな、論文読みましょう会があって、 自分で担当してめちゃくちゃ頑張って読み込んで、発表もしたんですけど、悲しいからほとんど内容を覚えていなくて、ただとても内容を理解するのが難しかったということしか覚えていないのですが、 また機会があればですね、復習というか、サイクロマティックコンプレキシティの定義とかどうやって計測するのかというと、このロジックを思い出せたらなぁなんて思ったりもしています。 このサイクロマティックコンプレキシティを理解すると何がいいかというと、複雑度が高いところは不具合が起こりやすいので、ちょっと雑に言ってますけど、 リファクタリングをした方がいいですね、みたいなことが言えるわけです。 あとはですね、前のチャプターでカバレッティっていうのは、プロダクトコードの品質が悪くはないよねっていうことが言えるぐらい。 で決して、単体テスト自体の品質だったり、プロダクションコードの品質が良いということはカバレッティでは表現できないという話がありました。 それを補完するためにですね、ミューテーションテストというものがあって、ミューテーションテストっていうのはユニットテスト、テストコード自体の確からしさというか、 クオリティが十分なのかということを確認する手法になります。 で、テストコードの自体の品質っていうのを考えるときに、さっき出てきたサイクロマティックコンプレキシティとかが影響する、そこの複雑度が高いところっていうのは、 品質が悪くなりやすいよねみたいな、高橋樹一さんの言葉を借りるとホットスポットっていう言葉かなと思うんですけど、 危ない箇所みたいな、怪しい箇所みたいなのが特定しやすくなるというか、特定する一項の要素としてサイクロマティックコンプレキシティが出てくるというわけになります。 はい、ちょっと本から脱線してしまったので本の方に戻りますけど、あとはですね、プロダクションコードをコードの複雑さとかドメインにおける重要性という観点から4つに分類してみました、みたいな、そういう分け方もなるほどな、みたいなところですかね。 ふむふむって思いながら読んでたりしました。この4つの分け方がそのままというか、ドメインモデル、一番ドメイン、重要なロジックが含まれているコードについては単体テストできちんとカバーしましょうねとか、 コントローラーについては統合テスト、インテグレーションテストでカバーしましょうねとかっていう、それ以外の取るに足らないコードとかは別にテストコードは必要ないですよねっていうところが書いてあったので、これが発祥のところなんですけど、まさにその、 単体テスト、インテグレーションテスト、一位テストの境目というか、どういう内容のテストはどこのテストレベルで実現するのが良いのかっていうところの参考になりそうだなというふうに感じてます。あとはですね、テストピラミッドが一番印象的だったのが、よいしょ、よいしょ。 あ、そうそう、単体テストではビジネスシナリオにおける異常ケースを可能な限り多く扱うようにしましょうというところですね。どうしても正常系を意識しがちに異常系って抜け漏れしやすい箇所かなというふうには思ってますので、いろんな異常系っていうところを異常ケースっていうのは単体テストで基本的にはカバーをすると。 で、インテグレーションテストでは一見のハッピーパスとか、あとは単体テストで扱えなかった異常ケースを扱うようにしましょうというところがあって、一個、なるほどというか、このセンテンスというかこの話はちょっと覚えておきたいな、忘れないようにしたいなというふうに思いました。 はい、ということですね。ちょっと本を読みながら雑音が入ったりとかもしたかなと思うんですけど、あとちょっと取り留めのない話というか、整理が仕切れてない状態のままお話をしてしまったんですけれど、読書ログと言いますか、思ったことをそのまま残してみたいなというふうな思いもありまして、今回はこんな形で収録をしてみました。最後までお聞きいただいてありがとうございます。 # 次回予告 今回も最後までお聞きいただき、ありがとうございました。 次回は、Voicyのトークテーマにのっとく質問力を高めるには、というお話をしようと思っております。 今回の放送を聞いて、なるほどな、確かにな、学びになったな、と少しでも思った方は是非、ハートマーク、いいねをお願いします。 フォローも是非よろしくお願いいたします。励みになります。 それではまた次回お会いしましょう。ごきげんよう。