Elevator Pitch
ユニットテストを書くことが重要なのはもちろんですが、費用対効果のよいユニットテストであることも重要です。それが実現できていない場合、ユニットテスト量が増えたときに様々な弊害をもたらします。このトークでは、費用対効果を高める上で、Goでどのように考え・実践しているかを紹介します。特に実装上Go特有の注意が必要な、適切なエラーハンドリング/エラーレポート・テストヘルパーの使い所・モック/スタブの使い所などについてです。このトークで紹介する基礎的な考え方と実践例が、参加者の方々の実践を支える基礎となることを期待しています。
Description
Goは、アサーションが提供されていない点など、他の言語と比較して特徴的な点がいくつかあります。しかし、 Goが何を考えてそうしているのか ・ その考え方は現場でのユニットテストにどのような利点をもたらすのか という基礎的な点を抑えると、応用的な取り組みも一貫した考えをもって実践できると考えています。
このトークでは、基礎の考え方として ユニットテストの費用対効果 という視点を紹介します。 費用対効果とは、テストによって得られる効果（削減コスト）と、テスト自身のコスト（発生コスト）のバランスです。このユニットテストのコスト については、『xUnit Test Patterns: Refactoring Test Code』という書籍でも、自動化テストの経済性 という言葉で言及されています。トークタイトルのCost-effectiveでおさえる基礎的な考え方は、ユニットテスト自身のコストに対して、ユニットテストによって得られる効果が高い状態を目指すものです。
この費用対効果という視点で、Goがアイデアとして示しているような適切なエラーハンドリング/エラーレポートやテーブル駆動テスト/サブテスト有効性について話します。
また、少し注意が必要とされている点についても言及します。たとえば、テストヘルパーやモック/スタブは、有効に使うと費用対効果を高める一方、使い所を間違えると費用対効果の低いユニットテストを生む可能性があります。そのため、これらについては、使用した際のメリット・デメリットを示した上で どのように判断するか を話します。
ユニットテストについて、「実データベースを使うか否か」・「テストフレームワークを使うかどうか」など時折議論の的に話題があります。これについても、業務アプリケーションで実践してきて得られた評価・アイデアについて言及します。
私は所属企業にて実践・自省してきました。その経験を踏まえた上で、 Goにおける費用対効果の高いユニットテスト のひとつのアイデアを示したいと思います。
トークの独自性
ユニットテストについてのトークは素晴らしい内容がたくさんあります。今回のトークの独自性は、WHYにより着目している点です。これまでのユニットテストのトークは、具体的な技法の紹介やテスタビリティ確保など、IntermediateあるいはAdvancedレベルの方々の到達点のHOWを紹介することが多いと思っています。 対照的に今回のトークは、 具体的なHow をトップダウンで落とし込むのではなく、 Why をベースにどう実践しているかを生々しく紹介するトークです。
構成
自己紹介 (1 min)
基礎的な考え方：費用対効果 (3min)
ユニットテストの 費用対効果 について説明します。ユニットテストがもたらす効果とユニットテスト自体の費用のバランスをどう捉えるかという視点です。
Goにおけるユニットテストの基礎 (5min)
Goで特徴的な点について、t.Errorf/t.Fatalfをうまく使い分けて適切なエラーレポート/エラーハンドリングすることや、テーブル駆動テスト/サブテストを活用することはよく知られています。この基礎的な技法について、費用対効果を高めるために実践する理由・それを達成するために意識するべき点について説明します。
主なキーワード
- 適切なエラーレポート
- 適切なエラーハンドリング
- テーブル駆動テスト
- サブテスト
- 外部テストパッケージ
Goにおけるユニットテストの実践 (10min)
すこし注意が必要な実践について話します。テストヘルパーやモック/スタブの使い所についてです。現場のコードベースによってこれは解が異なりますが、解を導くための判断の根拠を得るための、メリット・デメリットを説明します。実際に、私が現場で判断した結果のアイデアもここで話します。
主なキーワード
- テストヘルパー
- カスタムアサーション
- モック/スタブ
- 壊れやすいテスト（現状維持テスト/変更検知テスト）