Q&A
単語の意味を調べたら明確で、全く違うのが分かるはずですが、
どこからその疑問が出て、自身で調べたりしたのでしょうか。
何が問題でどう解決したのか具体的に記載してください。
単体テストとデバッグの違い
単体テストとデバッグの違いは何でしょうか？
デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
どこからその疑問が出て
業務において、新規画面作成をし、
単体テストの仕様書作成を依頼されました。
調べたところ、
「例えば、if文の分岐条件として、入力パラメータが5以下のみ正常処理とすべきところを、5を含めない実装をしていたとします。その関数に対して、テストパラメータとして、5を入力してテストを実施すれば、すぐこの関数にバグがあることがわかります。」
のように記載されていたのですが、
このレベルはもちろんデバッグで確認済です。
では単体テストに何のテスト項目を書けばよいのかわからず疑問に思いました。
＞何が問題でどう解決したのか
単体テストとデバッグの違いがわからないことを問題としました。
解決済であれば質問はしていません。
＞単語の意味を調べたら明確で、全く違うのが分かるはずですが
デバッグ→バグ修正まで含む
テスト→実行結果の確認。（バグ修正はしない）
と認識しています。
追加の質問となるのですが、デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
>どこからその疑問が出て
業務において、新規画面作成をし、
単体テストの仕様書作成を依頼されました。
調べたところ、
「例えば、if文の分岐条件として、入力パラメータが5以下のみ正常処理とすべきところを、5を含めない実装をしていたとします。その関数に対して、テストパラメータとして、5を入力してテストを実施すれば、すぐこの関数にバグがあることがわかります。」
のように記載されていたのですが、
このレベルはもちろんデバッグで確認済です。
では単体テストに何のテスト項目を書けばよいのかわからず疑問に思いました。
＞何が問題でどう解決したのか
単体テストとデバッグの違いがわからないことを問題としました。
解決済であれば質問はしていません。
＞単語の意味を調べたら明確で、全く違うのが分かるはずですが
デバッグ→バグ修正まで含む
テスト→実行結果の確認。（バグ修正はしない）
と認識しています。
追加の質問となるのですが、デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
テストを書いておくことのメリットがわかってないんじゃないかな？
質問を編集して追記してください。
＞業務において
指示者に聞くべきと思います。
業務上のことであれば、指示者や上司が意図や意味を最も理解しているはずです。
現場によってルールや意味や意図が違ってくるものでもあるので（用語の定義など特に）
自社のルールや意味をリーダーなり指示者なり上司なりに確認してください。
赤の他人に聞いて出てくるのはあくまで「調べてすぐ出てくる一般論」くらいのものです。
質問を追記いたしました。
>指示者に聞くべきと思います。
後日指示者に確認してみます。
私が記載したコメントは全て読みましたでしょうか？
>m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
>デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
こちらについてお答えいただくことは可能でしょうか？
「業務である」「指示者がいる」という時点で、赤の他人が答える内容ではなくなりました。
今ご自身でできるのは「調べた内容をもってそれが合っているか指示者に聞く」ことだけです。
先に書いたように赤の他人に聞いて出てくるのはあくまで「調べてすぐ出てくる一般論」くらいのものですので、私から出てくるのも調べてですぐ出てくるようなものだけです。
試しにご自身が調べた結果で参照した記事やご自身が2022/11/12 17:23にコメントをしたような根拠をきちんと質問本文に記載してみてください。
それに対して「Yes」「No」くらいは答えられますが、それが欲しいのですか？
でも考え方はプロジェクトによって違う部分はあるので、私が「Yes」と言った内容が指示者の観点だと「No」となった場合、二度手間三度手間になりませんか？
様々な考え方を取り入れてケースバイケースで適切に使えるのなら、今回みたいな質問してないと思うのですが。
＞それに対して「Yes」「No」くらいは答えられますが、それが欲しいのですか？
こちらが欲しいです。
>m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
m.ts10806さんが個人的に全く違うと思っているだけで、
上記の答えは「現場によって違う」という認識でよろしいでしょうか？
では以下ご対応ください。
>試しにご自身が調べた結果で参照した記事やご自身が2022/11/12 17:23にコメントをしたような根拠をきちんと質問本文に記載してみてください。
現状の質問内容本文が薄すぎて丸投げ且つ出所が何で何が問題なのか分かりません。
ご自身の2022/11/12 17:23のコメントを転記した上で、それぞれどういうキーワードで調べてどういう記事を確認してそう考えるに至ったのかを具体的に記載してください。
＞m.ts10806さんが個人的に全く違うと思っているだけで、
結構な数の現場やプロジェクトと役割を担ってきましたが、
さすがにこの２つを同じだと言ってる人は見たことないですね。
だからこそ「なぜこの疑問が出てきて自分ではどう調べてどう考えているのか」を
きちんと書いてもらう必要があります。
こちらはあくまで「修正依頼」を具体的にコメントする場所ですので、
こちらの書いたからと質問内容に反映されると思わない方が良いです。
（初期は非表示、１回開いても最新のコメント数件しか出ないから、目につかない）
コメントより既に詳細がわかっているのに、質問本文に記載する必要はあるのでしょうか？
それこそ2度手間です。
>それぞれどういうキーワードで調べてどういう記事を確認してそう考えるに至ったのかを具体的に記載してください。
上記についても今更不要ですよね？
これがわからないと下記質問に答えられないのでしょうか？
>m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
＞それに対して「Yes」「No」くらいは答えられますが、それが欲しいのですか？
※"答えられますが、"と記載しているのに答えられない理由はなんでしょう？
2022/11/12 18:01の中盤以降を参照。
「コメントで書いたからもういい」というのは今後見る人への配慮に欠けます。
さすがにそこで手を抜く人に対して何か手を差し伸べようとは思いませんし、
先に書いたように「業務である」「指示者がきちんといる」という時点で９割以上の人は遠慮したい案件なんですよ。
それでもと”あなたが依頼している”わけですから、こちらの言い分は飲んでいただきたい。
赤の他人の厚意で成り立っている場所ということをお忘れなく。
質問者はお客様ではなく、１ユーザーです（回答者ももちろん１ユーザーです）
質問追記いたしました。
で、下記にお答えいただくことは可能になったでしょうか？
>m.ts10806さんが"全く違う"と表現したのは具体的に何がどう全く違うのでしょうか？
＞それに対して「Yes」「No」くらいは答えられますが、それが欲しいのですか？
※"答えられますが、"と記載しているのに答えられない理由はなんでしょう？
「調べた」と書いてあるだけで参照した記事がありません。
私見ということで解釈してよろしいのでしょうか。
既に確認したような記事が参照先として提示される可能性もあるのでそれこそ二度手間三度手間です。
再掲
＞現状の質問内容本文が薄すぎて丸投げ且つ出所が何で何が問題なのか分かりません。
＞ご自身の2022/11/12 17:23のコメントを転記した”上で”、それぞれどういうキーワードで調べてどういう記事を確認してそう考えるに至ったのかを具体的に記載してください。
補足です。
＞既に確認したような記事が参照先として提示される可能性もあるので
これは回答する可能性があるのは私だけではないからです。
https://teratail.com/questions/usjqd3cf4lq81d
まったく同じ質問でした。
> それこそ2度手間です。
質問本文に追記あるいは修正した後で、コメント欄に「質問に追記しました。」と書くのが
他人に親切なやり方です。
同じ事を両方に2回書かれても見にくいだけです。
>同じ事を両方に2回書かれても見にくいだけです。
完全に同意見です。
ですので、コメント欄に書いたのであれば質問文への追記は意味ないのでは？
と提案したのですが、m.ts10806さんの熱い要望により質問文にも追記しました。
> ですので、コメント欄に書いたのであれば質問文への追記は意味ないのでは？
それは間違っています。
情報の追記は、質問文に書くのが正しいのですが、誤ってコメントに書いてしまった場合には、
質問文に追記した上で、コメントを編集して、該当部分を消します。
そのお作法は知りませんでした。
以降そのようにしますね。
結局下の質問には答えてなかったけど
回答できてんじゃん笑
＞現状の質問内容本文が薄すぎて丸投げ且つ出所が何で何が問題なのか分かりません。
＞ご自身の2022/11/12 17:23のコメントを転記した”上で”、それぞれどういうキーワードで調べてどういう記事を確認してそう考えるに至ったのかを具体的に記載してください。
追記がないのでそれを抜かした憶測で勝手に書いてます、
ただ、当の本人の反応が非常に気持ち悪いので（何一つありがたみを感じてない。煽ることに終始して本来どうすべきかを忘れてる）、またずっと複数アカウントで荒らしまわっているユーザーの嫌がらせ投稿もあるので、全て削除依頼を出しています。私の回答もミニマムに修正しておきます。
お幾つか知りませんが、業務ということは社会人なのでしょう。
最低限の礼節もなく、気持ち悪い顔文字（赤の他人相手にこういう場面で使うのはマイナスにしかならない）に煽ってばかりで対応として問題ないのかよく考えてください。
あなたの態度で疑われるのはあなた自身だけでなくあなたの上司や会社です。
>「コメントで書いたからもういい」というのは今後見る人への配慮に欠けます。
今後見る人への配慮は良いのでしょうか？
せっかくお答え頂いた回答を自分のみならず、今後見る人も見られなくなってしまうのは非常に残念です。
＞せっかくお答え頂いた回答
口だけは結構です。そもそもの前提とそこに至るまでのやりとりとあのコメントだけで払拭できないくらいの悪印象を与えた自覚はないんですね。赤の他人ということがずっと抜けている。
何度も書いてますが、調べて出てくるような内容。別に残す必要なし。
見ようと思えば見れるので、見方を知ってる人だけどうぞ。ただし、運営には削除依頼済み。
私はこれ以上関わらない。回答に修正依頼ついてもコメントついても何もしない。
今後見る人への配慮のために、m.ts10806さんの要望もあり、コメントと質問文追加など逐一行ったのですが、
>何度も書いてますが、調べて出てくるような内容。別に残す必要なし。
だったのですね。
何か矛盾を感じますが、承知しました。
この度はご回答いただきありがとうございました。
陰謀論か...
私は荒らしではない。
「スパムと見受けられる内容を含む回答」
「攻撃的な表現などを含む不快な回答」
「情報が古くなった回答」
とのご指摘がございました。
こちらは自己解決としておりますが、
m.ts10806さんが1度回答したものの、"今後見る人への配慮を忘れ"削除してしまったものを復元しております。
以降回答内容についてのご指摘は、m.ts10806さんへお願いいたします。
回答4件
0
デバッグ：問題解決の手段
単体テスト：工程の１つ
レイヤーが違う。並列にするのはおかしい。
※個人的な事情で申し訳ないですが回答大半削ってます。
投稿2022/11/12 09:40
編集2022/11/12 14:07総合スコア80888
0
ベストアンサー
こちらの回答が複数のユーザーから「質問に対する回答となっていない投稿」という指摘を受けました。
とのご指摘が多数あったため、ベストアンサーを修正いたします。
尚、こちらは参考になった回答を引用しております。
前提
質問者は業務且つ指示者がある状態で本質問を投稿してきており、
質問者が所属するプロジェクトと定義や意味が違う可能性があります。
つまり、私の回答によってプロジェクトの方針と違ったとしても一切の責任は取りませんし、
赤の他人なので責任を問えないということは了承ください。
デバッグ：問題解決の手段
※様々な意見を聞くのはもちろん良いことだが、様々な方向性の意見を取り入れて適切に使い分けできるなら今回のような質問はしないはずなので
単体テスト：工程の１つ
一般論（というか私の経験上）
デバッグ：手段
単体テスト：工程
なのでそもそものレイヤーが違います。
レイヤーが違うので、並列にするのはおかしい話です。
レイヤーが違う。並列にするのはおかしい。
問題の調査から解決までの一連を広義で「デバッグ」と称し、
「調査」の過程自体を狭義で「デバッグ」と称すこともあると思います。
故に、
デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
上記は大きく「No」です。
「開発した」ということは、まだ製造工程にあるはずです。
開発段階で起きた不具合はあくまで点に過ぎず、単体テストによって「機能」を確認した時に
不具合が起きないことを担保するわけではないからです。
「要件通りできていること」を確認するのが「テスト工程」（単体テストに限らず）。
段階に限らず問題が起きたときに解決策として用いる手段が「デバッグ」
むしろデバッグせずに開発ってどんな天才？
プロジェクトの慣習かもしれないので、あくまで私個人としてその考え方には疑問しかないです。
ただ、「この工程が必要かどうか」を判断するのはプロジェクトのマネジメントを担当している人なので、
「こういうケースはテスト不要」というのがプロジェクト方針として定義されていれば、「不要」でしょうけどね。
一般的に「確認したよ」って言葉だけでエンドユーザに提供するアプリケーションやシステムをリリースする現場って、数人だけで回してる社内システムくらいしかないと思うので、大抵は「どういう確認をすればこの機能はリリースできるか」という観点で単体テスト仕様書を作って、１つ１つチェックして全てOKになるまでテスト工程は終わらないわけです。
不具合があれば修正し、再度テストを行う（どこまでテストを行うかは影響範囲次第ですし、仕様不良なども見つかれば設計書の修正からまた追加実装し、追加テストを行うこともあるでしょう）
若干殴り書きになってしまいましたが、全部理解するのは現段階では難しいと思うので、
「一般論」冒頭に書いた「手段と工程なのでレイヤーが全く違う」というところだけ念頭に置いて再度考えてみてください。
投稿2022/11/12 15:09
編集2022/11/12 15:12退会済みユーザー
総合スコア0
「スパムと見受けられる内容を含む回答」
「攻撃的な表現などを含む不快な回答」
「情報が古くなった回答」
とのご指摘がございました。
こちらは自己解決としておりますが、
m.ts10806さんが1度回答したものの、"今後見る人への配慮を忘れ"削除されたものを復元しております。
以降回答内容についてのご指摘は、m.ts10806さんへお願いいたします。
0
Text
1単体テスト: 各要素のテスト 2デバッグ: コンパイルエラーの発見
投稿2022/11/12 10:07
総合スコア481
修正依頼は遊びで使う機能ではない。
名乗り出よ。
無言低評価禁止
無言低評価禁止
5chで誹謗中傷するな。
誹謗中傷禁止FUCK
誹謗中傷は倫理に反する行為である。
0
指示者に確認します。
m.ts10806さん、有益な情報は何一つ教えていただけませんでしたが、
何往復ものコメントを残していただき、ありがとうございました。
投稿2022/11/12 09:23
退会済みユーザー
総合スコア0
「こちらの回答が他のユーザーから「質問に対する回答となっていない投稿」という指摘を受けました。」
という連絡が来ましたが、こちらはm.ts10806さんの回答です。
自分も質問に対する回答となっていないと思いますが、埒が明かないのでこの質問は閉じたいと思います。
※コメントより
＞業務において
指示者に聞くべきと思います。
あぁ終わりでしたか。（回答って案外労力いるんですよ。補足などしておかないと説明不足で、後から見た人の参考にならないし。私はあまり質問者だけに分かったらいいという回答はしません）
でしたら、私の回答は削除依頼しときましょうか。
※こちらの回答に修正依頼をしたのは私ではないですが、私は「指示者に聞けって言われてそれで終わるなら質問自体なくしてもいいんじゃないか」と思います。
前提とか補足とかもしっかり書いた回答書けるなら、最初からそれ書いてよ～(*´з`)
ありがとう(*´ε`*)ﾁｭｯﾁｭ
ごめんなさい。物凄く気持ち悪いです。
それに調べて出てくるような内容を書いただけ。何も真新しいことはないはずですが。
やはり答えるんじゃなかったと、後悔しています。ここまで気持ち悪い上から目線のコメントが返ってくるとは。
頭は大丈夫ですか?
m.ts10806さんも上から目線である。
修正依頼は遊びで使う機能ではない。
名乗り出よ。
5chで誹謗中傷するな。
また、「頭は大丈夫ですか?」は「修整依頼集めと人格否定」ではない。
あなたの回答
tips
プレビュー
