意味のあるテストコード、意味のないテストコードの区切れ目はどこだとおもいますか？

Question

先日コードを書いて先輩にコードレビューをしてもらっていたところ「テストコードが無いから書いて」と言われました。
今回書いたものはWebサーバーアプリケーションの一部で特定のパスにリクエストが来たらデータベースから値を返すようなものです
具体的には以下のようなものです（パスやSQLは実際のものとことなりますが、ほかは特に簡略化しているわけではありません）

パス/getAllにリクエストがきたらデータベースにSELECT * FROM itemsを発行して値を返す

何をテストしたらいいかと聞くと「ちゃんと/getAllにリクエストしたらアイテムが全部返ってくるかテストして」と言われました

上で書いたように実装としては本当にこれだけです
テストすることが全くの無駄とは思いませんが複雑なコードではないので必要性が全くわかりませんでした
テストコードを書くのは大変でテスト用のデータベースをセットアップして値を放り込んでリクエストを模倣してサーバーに投げるということをしなくてはならないのでとても億劫です

テストを書いたほうがいいとき、書かなくてもいいときってみなさんどういう基準でやっていますか？
また、上で書いたコードにテストをする必要はあると思いますか？

Comments

[Zuishin]

/getAll だけじゃなく他にもデータの取得テストはしなくちゃいけないんでしょう？
そのうち一番簡単なものを一番の新米に任せたってだけじゃないですか？

Answer 1

質問者の視点が局所的というかミクロすぎてストレートな回答がしづらいけど

テストを書いたほうがいいとき、書かなくてもいいときってみなさんどういう基準でやっていますか？

テストを書いたほうがいいとき：品質保証が必要なとき
テストを書かなくてもいいとき：品質保証が不要なとき（書き捨てのコードとか）

まぁ、そもそもプロジェクトの品質目標達成に必要であれば書く。
それ以外に判断基準はないけど。

また、上で書いたコードにテストをする必要はあると思いますか？

「テストする必要」はある。
「テストコードを書く必要」があるのかは第三者に判断できない。

ここは厳密に意味が違う。

当然、上記の「テストを書いたほうが良いとき」の話の「テスト」も、「テストケース」か「テストコード」かで意味が違う。前者として回答してるけど。

手動テストで確実にコードの品質が担保できる、という判断があるなら、別にテストコードという形でなくても良い。

どのテストフェーズで、どんなテスト手法で「このコードは仕様通りちゃんと動きます」という保証ができるのか、という事はそのプロジェクト内で決めることなので、第三者に質問されても「知らんがな」としか答えられない。

つまるところ、プロジェクト全体を通して、そのコードがどのような形で品質を担保されているのか、という視点を抜きに判断できる話ではなく、当然テストケースが単純なのか複雑なのかで必要性が変わる話じゃない。

「大変」とか「億劫」はまた話のレベルが違って（別回答でも指摘があるけど）そこに手間や工数をかけないでも良いように改善する余地はあるだろうけど、それを考えるのはテストの責任者（専任が居なければプロジェクトリーダーやらそれに準ずる立場の人）なので、相談して決めるしかない。

自分から「こういう方法で工数削減できます」と提案ができるのが一番いいけど。

Comments

[gentaro]

付け加えるなら、要するにどうやってそのコードを品質を保証するのかは第三者にわからない以上、ここで質問したところでせいぜい得られる回答ってのは「安全側に倒す」という原則に従って「必要だ、書け」としかならないので、得られるものがない気がする。

[gentaro]

もうひとつ付け加えるなら、たぶん質問者は

「パス/getAllにリクエストがきたらデータベースにSELECT * FROM itemsを発行して値を返す」

というテスト対象の単純さでテスト要否を考えてるみたいだけども、単体テストフェーズで、大したロジックもなく複数のテストケースが存在しないから「こんなもんテストする必要あるの？」と思ったんだろうと推察するけど、結合テスト以降のフェーズなら「そもそもこの処理がちゃんと呼び出され、かつDBまで到達し、そこから値を取ってくることができているのか？」というのは必ず確認するべき、というのは納得できるんじゃない？

我々第三者はその確認をどのフェーズでできているのか知らんので、「これが必要か？」と聞かれても答えられないけども。

Answer 2

テストの必要ないコードはありません。
分岐や呼び出し元が増えたら当然テストしなければなりませんし、
「思ったように書けたからOKだろ」と言っていたらどんな簡単に見えるコードでも不具合の温床となります。
利用者は制作者の思った通りには使ってくれませんしね。

というか、テストコード書くよりもテストケースやテストシナリオ作成が先です。
※別途ケースに指示があるなら先に聞いておくこと

詳細設計書をINPUTに実装をOUTPUTとするのと同じように、
テストケース・テストシナリオをINPUTにテストコードをOUTPUTとします。

※ただ質問タグ「テスト駆動開発」をそのまま真に受けると「テストがない実装」ってありえない

テスト駆動開発

テスト駆動開発は、 プログラム開発手法の一種で、 プログラムに必要な各機能をテストとして書き、 そのテストが動作する必要最低限な実装を行い コードを洗練させる、といったサイクルを繰り返す手法の事です。

---

テストコードを書くのは大変でテスト用のデータベースをセットアップして値を放り込んでリクエストを模倣してサーバーに投げるということをしなくてはならないのでとても億劫です

言語や環境不明ですが、環境変数とか設定ファイルとかでテストコード実行時はテスト用のDB参照するように作っておけば良いのではないでしょうか。
プロジェクト運用の話だとは思うので、出来ること出来ないことはありますが、フレームワークなどつかってればうまいことテストやりやすいように（モックとか）出来てたりします。

そして、「億劫だから」「面倒だから」と省略した箇所に大抵不具合が発生します。