Q&A
プロジェクトの性質によって変わるので一概には言えないのでは。
同僚と一対一で揉めてるならどっちが相手を説得しても角が立つので第三者（普通はいわゆる「上司」）に相談して判断してもらうんじゃないかな。
> （できれば同僚を説得したいです）
何が大事だと思っているのかが気になります。
C言語で組み込みの開発をやっています。
今担当しているソースには下のようなソースがたくさんあります。
ユニットテストでの確認対象としては、なんとなく下記のような事が考えられますが、みなさんはどの程度までユニットテストで確認していますか？
可能なら、その理由も教えて頂けると助かります。
担当しているプロジェクトでのユニットテストの方針を決める上で参考にしたいと思います。
1)関数の戻り値（例はvoidですが・・・）
2)グローバル変数の出力値
3)関数コールの有無（スタブを作成して確認）
4)関数コールへ渡す引数の値（スタブを作成して確認）
5)呼び出し先関数の中身も考慮した出力値
※当初の質問内容では、期待していた回答をなかなか得られていなかったので、質問内容を大幅に修正させて頂きました。すでに回答してくださった方、ありがとうございます。
c言語
1int value; 2 3void func(){ 4 value = funcXYZ(); 5 if(value == x){ 6 funcX(x); 7 funcA(); 8 }else{ 9 funcX(a); 10 funcB(); 11 } 12}
>（できれば同僚を説得したいです）
ご自身では、ユニットテストでどこまで確認すれば良いと思っているのですか？
> 各呼び出し関数のスタブを作成し、関数がコールされることや呼び出し先関数に渡る引数が正しいかを確認しています
IN/OUTの確認ですから、最低限のテストに思えますけど。
> 各呼び出し関数のスタブを作成
スタブを作ってまで・・・という事なら粒度ではなく手段の話です。
bboydaisuke 様
（できれば同僚を説得したいです）と記載したのは、関数コールや引数まで確認しても費用対効果は薄く、後からテストケースのメンテも大変になると思っていたので、あまりそういったことに工数をかけてほしくないのでなんとか説得できないものかと思って記載していました。
ただ、自分もそんなに経験もあるわけではないので、すこし余分な文言でした。なので質問からは削除します。
sazi様
＞ご自身では、ユニットテストでどこまで確認すれば良いと思っているのですか？
ユニットテストは関数の入力に対する出力結果を確認するもので、関数コールは結合試験の範囲内で確認するものと思っていました。
確かに粒度はおかしな表現だったかもしれません。テストの確認対象を、戻り値、グローバル変数の出力値、関数コール有無、関数コールの引数のようにどこまで確認すべきかという意味合いで粒度と使っていました。
回答6件
0
ベストアンサー
通常のユニット(単体)テストと言うのは、一つの関数を引数を変えながら複数回呼び出し、そのすべてにおいて正しい戻り値が返ってくることを確かめるものです。
つまり、想定した引数に対して想定した結果が得られるならば、関数の中で何が行われていようが、まったく問題にしません。したがって、普通なら同僚の意見は間違っていることになります。
しかし、質問に掲載されているケースにおいては話が異なります。
なぜなら、func() には引数も戻り値もなく、グローバル変数を変化させているからです。そしておそらく中で呼ばれている funcA funcB funcX funcXYZ に関してもそのような作り方がなされている、あるいは将来なされる土壌があると想像できます。
この場合、func() の中で何が呼ばれるかによって、また func がいつどのように何回呼ばれるかによって、グローバル変数の何がどうなるかが変わってきます。
要するに、func() を単体テストすることはできません。func() へのテストに関しては自動的に結合テストになります。
したがって、この場合正しいのは同僚です。関数の呼び出し順や回数によってどの変数がどこでどのように変わるかを保証できない以上、品質を担保するためには関数の中身まで細かくテストする必要が出てきます。
テストについて考えられず作られたコードにより、事実上テストの効力が崩壊しているので、テスト云々より先にコード自体を書き直す必要があると思います。
投稿2020/07/18 09:52
総合スコア28660
全て察して頂いたとおり、グローバル変数で関数間、モジュール間が繋がっている状態です。ソースの可読性もよろしくなく、リファクタリングの必要性は常々感じていますが、リファクタリングするにもパワーがいるため全然できずにいます・・・。
話を単体試験に戻すと、自分もこのような関数はほぼ結合試験の範疇内で自動的に確認する形になるかなと思っておりました。なので単体では必要最低限の確認をし、結合試験に力をいれる形を取っていました。ただ逆に、動作の保証が難しいから逆に細かくみる必要性が出てくるという考えもあるのですね。言われてみればそうかもしれませんが・・・。ただそれは工数が余計にかかることにもなるので、ソースを地道に治していくのがなんだかんだでいいのかもしれません。
いろいろとアドバイスありがとうございました。
0
個人の趣味でやっているプログラム開発ならともかく一定規模のプロジェクトだとすると、そういうことは個人個人の裁量で判断することではないです。
あるテストフェーズでどの程度のことまで確認するかはプロジェクト全体で揃えておかないといけないことなので、個人間の話し合いで解決する内容じゃないと思います。意見が分かれているのであれば、判断できる人に判断を仰ぎましょう。
追記：
前提は上記に書いた通りですが、与えられた情報を元にあえてどちら側の意見を支持するかを言うとするならば、個人的には同僚の方のほうですかね。ユニットテストをやるのならば、IN/OUTは確認するのが普通かなと思うので。
投稿2020/07/17 14:07
編集2020/07/17 17:35
総合スコア133
リーダーの判断を仰ぐにあたり、一般的にはどうしているのだろうと思い質問した次第です。
自分の質問の仕方も悪かったので質問内容を修正しました。
正直、同僚のやり方を見た時、えっ！って思いましたが、別にそこまで驚くことではないのですね。参考になりました。
IN/OUTの捉え方次第ってことですかね。関数コールをOUTと捉えるか。呼び出し先関数の引数は言われてみれば、OUTと捉えることもできるかな思えました。
回答ありがとうございます。
受け取ったデータを適切な値に変換して外部に渡してやることは、その関数の責務です。そう考えると呼び出す関数にも意図したデータを渡しているかどうかを確認するのは普通かなと思います。修正された質問だと1〜4は、確認しててもおかしくないかなと思います。
一方で、人によってやっていることがバラバラなのも問題です。このテストフェーズでは、ここまでの確認すればOKということで揃えているから今まで通りのやり方でやっていきたいという意見を主張するのはない話ではないかなとも思います。
そのために、今までのやり方で最終的な品質は保証されてきたとか、費用対効果を考えるとそこまでやるメリットがないとかの根拠を示す（1週間時間をかけたのに数個しかバグが発見されなかったなど）ということをしてはいかがでしょう。
そんな感じでチームで話し合って（個人間ではなく）、どういった線引きをするのか決めるのが良いと思います。
関数Ａが自身の機能を実装するために別の関数Ｂを利用しているとき，
「関数Ａが別の関数Ｂを呼び出す」ことをテストするのだとしたらそれは無意味な話に思います．
（もちろん，関数Ａの仕様に「Ｂを呼び出すこと」とあるのであれば話は別ですが）
テスト対象が関数Aなのであれば、それに対するIN/OUTは確認すると思うので関数Bを呼び出すことも確認するのではないでしょうか。そうではなく、テスト対象が関数A、Bを含む機能なのであれば、それに対するIN/OUTと考えると機能の内側に含まれる関数Bの呼び出しは気にしないということになるかと思います。今回のケースは、どちらかと言うと前者だと認識したので、それを元に回答しました。
0
まず、表題の「ユニットテストでどこまで確認するのか？」という問いに対しては、
明確な基準は存在しません。
という回答になります。
一般論としてユニットテストでどのような事がテストされているのかについてはテスト技法の書籍等を読まれると良いと思いますが、@hytNInE の回答にあるのがまさにそのままで、ちゃんとしたプロジェクトであれば、そのプロジェクトごとに基準を設定しておくべき事であって、個人個人が勝手に判断するものじゃありません。
回答としてはこれで終わりなんですが、考え方として、まず何のためにテストを行うのか？というと、それはそのソフトウェアの品質を保証するためです。
では、「品質」とは何かというと、これは一つの指標としてISO/IEC 9126等で表されています。
これらの「品質」をどのテストフェーズでどのぐらい確保していくのか、という視点でテスト計画を立て、それに従って個々のフェーズのテストに求められる基準を作成するのが、プロジェクト責任者や、責任者に任命されたテスト管理者の仕事です。
極端な話、ユニットテストなど一切実施せずに、製品が完成してからテストを実施する（ビッグバンテストと呼ばれる方法）もあり得ますし、昔はそうした事もよく行われていました。
これは何が良い・悪い、という話ではなく、プロジェクトの方針次第です。
重要なのは「ユニットテストでどこまでやるべきか」は個別に決まるわけではなく、テスト工程全体の中でどのように位置づけられるかに左右される点です。
そのため、全体を俯瞰して考える立場じゃない人が議論しても決まらないどころか、個々のテスト内容に差が出てしまい、結果として漏れやダブリが発生するため、必ず責任者の判断を仰ぐ必要があります。
投稿2020/07/17 15:47
編集2020/07/17 15:52
総合スコア8949
責任者の判断を仰ぐにあたり質問内容を知りたかったのです。開発自体、5，6人でやっている程度なので、自分の意見もすぐに反映される状況にあります。
なのでユニットテストの確認内容の線引きのために参考にしたかった次第です。
ただ本音では、費用対効果からできれば関数コールの確認をやらない方針に持っていきたく、やらなくてもいいという理由付けが欲しかったです。あとは他の開発ではどうしているのか？という素朴な疑問もあり質問させて戴きました。
プロジェクトの明確な基準がないのであれば、「安全側に倒す」のが基本です。
目先の工数（手間）の削減が、将来の不具合修正という手間となって跳ね返る可能性があるからです。
上長に提案する上で、もし「○○のテストは不要」という主張をするのであれば、それはなぜ不要なのか（そのテストで担保できる品質は、代わりにどの工程で担保できるのか）という明確な理由付けをして説明する必要があります。
あなたがそれを説明できるのであれば問題ありませんが、ここで聞きかじった程度の内容で提案するのは正直お勧めしません。それよりも、その検討の過程を含めて上長と話し合いましょう。
0
このような関数の場合、みなさんはどういったユニットテストを実施しますか？
真面目な同僚は各呼び出し関数のスタブを作成し、関数がコールされることや呼び出し先関数に
渡る引数が正しいかを確認しています・・・
個人的にはそこまでがんばる必要はないと思っているので、どの粒度で確認すべきかで同僚と揉めています。。。
一般的には、決めるのはプロジェクトリーダーなりITアーキテクトなりでシステムの全体を見る人であって、個々のプログラマーではありません。
単体テストに限らず、人や機能によって粒度が違えばプロジェクトの品質に関わります。
品質に関わることを個々のプログラマーで決められることではないし、元々決まってないとおかしいです。
レビューは誰がするのですか？
レビュー観点が分かってない状態で（言い方悪いけど）末端があれこれ言っていても仕方ないですよ。
投稿2020/07/17 19:44
総合スコア80850
質問背景を少し説明すると、
元々は関数コールの有無までは確認していませんでした。そこに同僚が入ってきて関数有無の確認までするようになり、人によって記載の違いが出てきてしまいました。それを統一するためリーダーに言いたいのですが、その前に一般的にはどの程度確認しているのか？とその理由を知りたかった次第です。
一般的にはリーダーやマネージャーが決めるものという回答ですが。
「自分が正しい」と通したい前提なら人にアドバイス求めるのは間違いですよ。
0
関数がコールされることや呼び出し先関数に渡る引数が正しいかを確認しています
そのような事柄に「不安があるのか否か」次第．
不安ならば，不安が無くなるまでテストするしかない．そこに選択肢はない．
逆に，不安が無いような事柄を隅々までテストするのは「時間の無駄」になる率が高いわけで，
それをやらずに先に進んだ結果として，何らかのミスが「もうちょっと後で」見つかることになったとしても，
それを探して修正する時間というのが，十中八九無意味なテストを大量にやっている時間と比較してどうなるか？ というのを考えたらよいのではないかな，と．
（もちろん，無限の時間と労力をかけられるならば，いくらでもテストすればよいのだろうけど，現実はいつも厳しい．）
投稿2020/07/17 14:44
総合スコア11658
あと，あなたから見て「そこまでやる必要は無い」と思えることを行っているがためにその同僚の進捗が遅くて困るだとか，そういう問題が具体的に出てこないうちは好きにさせておいたほうがよいかもですよ．説得とかせずに．
「不安があるのか否か」は1つの視点として考えたいと思います。不安の感じ方と時間の無駄の感じ方が同僚とかなり違っているのかもしれません・・・。
費用対効果のデータを出せれるかちょっと試してみようと思います。
アドバイスありがとうございます。
0
こんにちは。
テストに掛ける工数も当然「費用」です。「費用」は少ないに越したことはありません。
しかし、テストしないで信頼性の低いプログラムを納品するのは有りえません。そもそも約束した機能を満たさないプログラムでは売上が立ちません。
ということは、約束した機能を満たしていることを検証するテストに注力し、それにあまり貢献しないテストは省略した方がより満足度の高いプログラムを納品できると思います。（新人さんが多い場合や、人の命に直結する医療機器のようにテスト工数を十分に掛けるべきケースでは別ですが。）
単体テストでは各パーツを組み合わせた時に意図通り動作することを確認できません。また、実際に組み合わせた際に入力されることがありえないケースも多々あり、それらをテストすることは無駄打ちが多いと感じます。
投稿2020/07/17 13:31
総合スコア23272
あなたの回答
tips
プレビュー
