質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
ソフトウェアテスト

ソフトウェアテストは、プログラムを実行し、要求通りに正しく動作が行えているかどうか確認する作業です。プログラム中のバグをできる限り多く発見することを目標として行われます。

ユニットテスト

ユニットテストは、システムのテスト手法の一つで、個々のモジュールを対象としたテストの事を指します。対象のモジュールが要求や性能を満たしているか確認する為に実行します。

Q&A

解決済

1回答

554閲覧

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

noc

総合スコア73

ソフトウェアテスト

ソフトウェアテストは、プログラムを実行し、要求通りに正しく動作が行えているかどうか確認する作業です。プログラム中のバグをできる限り多く発見することを目標として行われます。

ユニットテスト

ユニットテストは、システムのテスト手法の一つで、個々のモジュールを対象としたテストの事を指します。対象のモジュールが要求や性能を満たしているか確認する為に実行します。

0グッド

1クリップ

投稿2020/12/30 03:27

編集2020/12/30 03:29

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

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

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

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

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

m.ts10806

2020/12/30 03:51

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

2020/12/30 03:57

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

2020/12/30 04:07

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

2020/12/30 04:25

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

2020/12/30 04:35

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

回答1

0

ベストアンサー

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

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

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

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

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

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

投稿2020/12/30 03:57

gentaro

総合スコア8949

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

noc

2020/12/30 04:24

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

2020/12/30 05:22

ホワイトボックステスト、ブラックボックステストの違いについてはググればいくらでも説明があるんで調べてください。 > しかしながら実装内部がごっそり変更されたときそれまで作っていたホワイトボックステストが無駄になることを考えると そもそもなんでそんな事態が発生するのかを考える方が先。 製品コードでプロトタイピングやってるんですか? 普通はそういう手戻りを避けるため、ある程度仕様が固まって変更可能性の少ないものから着手する。 その上でやむを得ない事情で変更が必要になったらテストを含めて修正する。 その際、変更が不要なものまで変更してしまうミス(デグレード)が発生していないかを確認する(リグレッションテストを行う)ためにもテストの作成は先にやっておく必要がある。 逆に言うと、仕様的に強固で変更する可能性の低いものから順次テストを作成すりゃいいだけで、変わるかもしれないコードを書いてる時に馬鹿丁寧にテストを書くのは、単に「要領が悪い」としか。
noc

2020/12/30 12:28

> 製品コードでプロトタイピング イメージとしてはそれに近いですね。作り終えて実際に動かしてみて、はじめて気づくことが多いのです。まぁ今回のように外部的な仕様が固まっているときには変更点は少ないでしょうが、アルゴリズムの変更やUXの不快感からのUIの変更は抜本的になりやすく、こういった揺らぎやすいものにテストを作るべきかと疑問でした。特にテストファーストという言葉を聞くと余計に。 > 普通はそういう手戻りを避けるため、ある程度仕様が固まって変更可能性の少ないものから着手する。 > 逆に言うと、仕様的に強固で変更する可能性の低いものから順次テストを作成すりゃいいだけで、変わるかもしれないコードを書いてる時に馬鹿丁寧にテストを書くのは、単に「要領が悪い」としか。 実験的に実装し、それを足掛かりに他の部分を実装していくスタイルでは、「ここは重要だろう」というところと、「変わることはないだろう」というところ以外はテスト作成を保留して、完成させて日数をおいて「安定している」ことが確認できたときに残りのテストを作成した方がよさそうですね。
gentaro

2020/12/30 12:37

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問