設計書としてのテストと、内部詳細としてのテストは分けるべきですか？そもそも内部詳細のテストは作るべきでしょうか？

Question

普段テストを書かなくて不慣れなのですが、複雑なモジュールを作る必要が生じまして、設計を考える段階でテストを先に書きました。
Xを与えられたらX'を返したい。Yを与えられたらY'を返したいといった感じで。
実装がないままテストに希望を書き連ねました。

そして設計が固まった段階で、いよいよ実装に移ることにしました。
引数として与えられた文字列をパースして配列や細かいオブジェクトに解釈した方が実装がうまくいくように思えました。
しかしこれは実装の詳細に当たるもので、先ほど作成したテスト一覧には含まれておりません。
このテストは作成するべきなのでしょうか。

先ほど作成したテスト（設計書としてのテスト）と、"実装の詳細のテスト" は別の概念のように思えます。実装方法を変更したところで "設計書としてのテスト" は変更されることはありませんが、"実装の詳細のテスト" は実装に追随する必要があるでしょう。
私としては、"実装の内部詳細についてのテスト" はあまり作りたくありません。詳細を変更することはしょっちゅうですが、そのたびにテストの方も修正する可能性が生じるからです。
また、"設計書としてのテスト" はテスト単体で見てもこのモジュールが何をするものなのかを適切に表しているドキュメントになっていますが、"詳細についてのテスト" は結局なにをやっているのか実装内部を理解しないと理解できないかと思われます。

どちらも単体のモジュールについてのテストなので、単体テストには違いないと思いますが、両方（設計書としてのテストと実装詳細のテスト）作る必要があるでしょうか？
もし作る場合はファイルを別に分けるなどした方がいいでしょうか？

ご意見をお聞かせください。

Comments

[m.ts10806]

前提は何でしょうか。
実務なら他人に聞くのは間違いでしょうし、本来はテスト内容や指針は設計時に決まっているものです。

[noc]

個人で趣味での開発です。
「本来はテスト内容や指針は設計時に決まっている」とはチームやマネージャーが決めるということでしょうか？そうであるならば個人で裁量が全て自分にあるときにはどうすべきでしょうか？

[gentaro]

個人なら好きにすりゃいいし、他人がどうこう言えるもんじゃない。
こういう「べき論」はあくまでチーム開発を前提にしたものだから、個人で同じことをしようとするのはほとんどの場合過剰。
それでもやるなら、あなた自身が「マネージャー」としての立場と「メンバー」としての立場で頭を切り替えろというだけの話では。

[m.ts10806]

自身の趣味ならさじ加減次第。
「何をもってオーケーとするか」は結局製品を作る人が決めることです。

[noc]

なるほど、ありがとうございます。

Answer 1

微妙にニュアンスがわからないけど、ブラックボックステストとホワイトボックステストの話をしてる？

基本的に、そのモジュールの利用者目線でブラックボックステストを作って利用者の要求する機能・非機能要件を満たすかを確認した上で、モジュールの作成者目線で必要だと思われる箇所（異常系の処理とか、複雑な内部処理フローが存在する場合はその確認など）についてホワイトボックステストを行えば十分だと思うけど。

概念がどうとかじゃなく、そのテストで保証したい「品質」って何なの？というところを考えた方が良いと思う。

私としては、"実装の内部詳細についてのテスト" はあまり作りたくありません。詳細を変更することはしょっちゅうですが、そのたびにテストの方も修正する可能性が生じるからです。

その変更の原因や頻度がわかんないけど、仕様が固まる前にプログラミングしてるのでなければ、仕様変更が起きたら実装済みの機能に何らかの変更が起きるのは当たり前で、じゃあそのテストを作ってなかったから簡単に変更できて楽でいいね、という立場を取るなら、いつその箇所をテストするんだろう？

そこを考えずに楽な方に流れるなら、それはテスト漏れを懸念してない事になるんで「そのテストを作っていたことで担保したかった品質」は下がるだけだけど。

Comments

[noc]

設計書としての役割が強い方のテストをブラックボックステストと呼ぶのですね。
確かに品質を考えるとホワイトボックステストを全くやらないのはよくないですね。
しかしながら実装内部がごっそり変更されたときそれまで作っていたホワイトボックステストが無駄になることを考えるとテストをする個所は複雑で間違いが起きそうなことをやってる箇所に絞り込んだ方がいいのではないでしょうか？

[gentaro]

ホワイトボックステスト、ブラックボックステストの違いについてはググればいくらでも説明があるんで調べてください。

> しかしながら実装内部がごっそり変更されたときそれまで作っていたホワイトボックステストが無駄になることを考えると

そもそもなんでそんな事態が発生するのかを考える方が先。
製品コードでプロトタイピングやってるんですか？

普通はそういう手戻りを避けるため、ある程度仕様が固まって変更可能性の少ないものから着手する。
その上でやむを得ない事情で変更が必要になったらテストを含めて修正する。
その際、変更が不要なものまで変更してしまうミス（デグレード）が発生していないかを確認する（リグレッションテストを行う）ためにもテストの作成は先にやっておく必要がある。

逆に言うと、仕様的に強固で変更する可能性の低いものから順次テストを作成すりゃいいだけで、変わるかもしれないコードを書いてる時に馬鹿丁寧にテストを書くのは、単に「要領が悪い」としか。

[noc]

> 製品コードでプロトタイピング
イメージとしてはそれに近いですね。作り終えて実際に動かしてみて、はじめて気づくことが多いのです。まぁ今回のように外部的な仕様が固まっているときには変更点は少ないでしょうが、アルゴリズムの変更やUXの不快感からのUIの変更は抜本的になりやすく、こういった揺らぎやすいものにテストを作るべきかと疑問でした。特にテストファーストという言葉を聞くと余計に。

> 普通はそういう手戻りを避けるため、ある程度仕様が固まって変更可能性の少ないものから着手する。
> 逆に言うと、仕様的に強固で変更する可能性の低いものから順次テストを作成すりゃいいだけで、変わるかもしれないコードを書いてる時に馬鹿丁寧にテストを書くのは、単に「要領が悪い」としか。
実験的に実装し、それを足掛かりに他の部分を実装していくスタイルでは、「ここは重要だろう」というところと、「変わることはないだろう」というところ以外はテスト作成を保留して、完成させて日数をおいて「安定している」ことが確認できたときに残りのテストを作成した方がよさそうですね。

[gentaro]

プロトタイピングは別に作成してそのコードは捨てるつもりでやるべき、とか、ビジネスロジックとUIは分離しろ、というのは割と常識的に言われてる事なんで、テスト云々よりそのやり方を見直す方が先だと思うけども。
まぁ個人の趣味でやってるなら好きにしりゃいいんだけど、だったら尚更こんなところで聞いてもたぶんあなたのやりたいやり方に沿う答えは帰ってこないと思う。