junit等のテスト自動化で、どこまで担保を取るかはどの現場でも議論になると思います。
現場でとても良いルール付けに巡り合えたので紹介したいと思います。
投稿の目的
無駄なテストコード作成を削減し、テストコードのメンテコスト削減
前提
今回はサーバーサイドの話です。
・コントローラ層 ：サービス層からの値を画面表示値に編集したりする責務
・サービス層 ：各機能処理の入り口
・ドメイン層 ：ビジネスロジックの責務
DTO、VOの詰め替えもここで行います。
・データアクセス層：DBアクセスの責務
担保範囲、ルール付け
コントローラ層
基本的にテストコード不要です。
なぜならコントローラは画面に関わるところですので、画面に関わるテストで担保が取れるので、junitなどのサーバサイドで担保を取るのは不要です。
複雑な処理がある場合は、その処理のみ切り出してそこだけ担保取るのが良いです。私の場合は別メソッドに切り出してその箇所のカバレッジのみ100％にしています。
サービス層
ここのテストを一番厚くすべきです。サービス層以下の結合テストをする勢いで担保を取ると良いです。但し、以下の担保は不要です。
・業務に起こりえない箇所の網羅。
・メソッドの呼び出し回数。
担保理由が不明だからです。戻ってきたアウトプットの検証で十分です。
ドメイン層
基本的に不要です。
サービス層での担保でカバーできるからです。
複雑なビジネスロジックがある場合は、メソッドに切り出してそのメソッドだけ担保を取ります。
例えば、金額の計算ロジック等は担保を取っておくと良いです。
データアクセス層
ここも厚くする箇所です。指定した条件で期待した登録、更新、参照できることを細かく担保しましょう。SQLの外部結合、内部結合条件も細かく網羅しましょう。
上記の細かいところはサービス層のテストでも良いですが、サービスのテストコードが大量になるのを防ぐため、データアクセス層のテストに任せられるところはお任せしましょう。
全体的
業務で起きないことは担保不要です。業務で起きないことを色々考慮し、増えた分岐は処理されないコードです。作成したコード量に応じてバグが増える可能性はありますし、テストコードも増えてしまいます。
苦い経験①
私はカバレッジ100％を目指し過剰な品質担保で、1週間ぐらいは工数を無駄に使ってしまったことがあります…ぐぬぬ
苦い経験②
この方法を考えた同じチームメンバーの方は、カバレッジ100%が必須だった現場で追加開発の度に多数のjunit修正が必要となりました。
その結果、保守性が悪くお金の折り合いがつかなくなりプロジェクトが無くなったそうです…
まとめ
今回はサーバサイドを例に挙げていますが、seleniumなどのその他テスト自動化も同じだと思います。
考慮すべきは「理由のある担保」と「メンテのしやすさ」です。