holmesの倉島です。テストコード記述に関連する個人的な疑問点を、意見・考えをまとめて自分なりの回答を出してみました。
- Q1: TDDで実装中に、別のテスト記述可能なメソッド(publicメソッド等)を実装したくなった。これもテスト対象？
- Q2: コンストラクタのテストコードは必要？
- Q3: テストの結果として想定している値は複数でも良い？
- Q4: TDDによる実装後のTODOリストの扱い
- Q5: テスト結果の検証を行う時 assertEqualsのように、 == や === を使用しないでメソッドを使用して比較する理由は？
- (最後に)おまけ
Q1: TDDで実装中に、別のテスト記述可能なメソッド(publicメソッド等)を実装したくなった。これもテスト対象？
TDDのred→greenの実装中に「あれ？次に書く予定のメソッドもTDDで実装した方が良いのでは？」と、ふと思い作業の手が止まってしまったので考えてみました。
結論を述べると、TDDでは実装しないで、書く予定のメソッドで他に試したいパターンがあるなら記述後に改めてテストコードを書く でまとまりました。理由としては、本筋のコードで通るメソッドであるため、ある程度の担保はされているからですね。
Q2: コンストラクタのテストコードは必要？
コンストラクタ内に分岐があり想定パターンが複数存在する場合はテストコードを記述するのはアリだと思います。
ただ想定パターンが複数存在しない場合、コンストラクタはいずれかのテストコードの範囲内の筈かつ、コンストラクタは言語(Lombok等を使用しているのであればライブラリ)の機能で信頼性が高いのでテストコードは不要だと思います。
Q3: テストの結果として想定している値は複数でも良い？
一つのテストコード内で(結果として判断できる値は)一つであることが望ましい。理由としては、複数の値を結果として想定していると手前で落ちた場合その後の値が評価されないからですね(アサーションルーレットアンチパターン)。ただ例外として、まとめて審査しないと意味がないもの(インテグレーションテスト等)は結果として複数想定する場合があります。
Q4: TDDによる実装後のTODOリストの扱い
捨てます。TODOリストは飽くまでTDDを行うための道標であって成果物ではないことと、自分が良い・解りやすいと思ったテストコードを記述できているのであれば(テストコードにTODOリストの内容が落とし込めているため)TODOリストは不要だからですね。
Q5: テスト結果の検証を行う時 assertEqualsのように、 == や === を使用しないでメソッドを使用して比較する理由は？
言語によっては==や===を使用した比較結果が異なる場合があるので、なるべくテスティングフレームワークのassertionに任せた方が良い、という理由ですね。
また余談として...、検証処理自体をテスティングフレームワークに移譲することによって、例えばテストが失敗した場合に、expectedとactualの差分をわかりやすく表示してくれたりなどのメリットがあります。
(最後に)おまけ
TDDを知って約1年半が経過しました。未来の自分に向けて、何故自分がTDDを続けているかの理由を少しだけ分析・記述しておきたいと思います。
恐らく一番の理由としては、単純に楽しいと思っているからですかね。TDDはred→green→リファクタリング のサイクルを回して実装を行う開発手法です、段々にステップを踏んで着実な一歩/前進を感じることができるので「楽しい」と思っている ですね。
Holmesでは現在エンジニアを募集しています。 興味がある方は是非こちらからご連絡ください！
