ｿﾌﾄｳｪｱ開発の仕事に携わっています｡｢開発途上のﾌﾟﾛｸﾞﾗﾑの品質が心配なので検査して欲しい｣という依頼を受けて10K行ばかりﾁｪｯｸしたところ､関数の返す結果値(正常に処理を完了できたか､何らかのｴﾗｰが発生したかを整数型の値で返す関数です)を9割がた未ﾁｪｯｸのまま正常処理を続行していることが判明しました｡ｴﾗｰ値をあつかうべきかどうか？はﾌﾟﾛｸﾞﾗﾑの重要性や
ｴﾗｰの致命度によると思います｡
ﾌﾟﾛｸﾞﾗﾑ自体が内部ﾒﾝﾊﾞだけが使うﾃｽﾄﾌﾟﾛｸﾞﾗﾑであれば
ｴﾗｰをほっておいてもいいかもしれないし､また逆に､一般ﾕｰｻﾞが
使うのであれば､きっちり何が起きているのか教えてあげる必要があると
思います｡また､そのｴﾗｰが発生して､それ以降の処理を継続しては
いけない(例えば過去のﾃﾞｰﾀを空白で上書きして消す結果になる)場合は
ちゃんと中断処理をする必要があると思います｡さらに例えると､
ｵｰﾀﾞ処理でｴﾗｰになったら､課金処理をﾛｰﾙﾊﾞｯｸさせるとか､､
逆に､軽微なｴﾗｰであって､一度発生してもまたﾘﾄﾗｲするﾀｲﾐﾝｸﾞが
あって､その時にうまくいけばいいのであればほっといてもいいし｡｡
一般的に､ｴﾗｰ処理はまじめにやりだすと､ｺｰﾄﾞが肥大化して読みにくく
なるし､さらに､ｻﾌﾞﾙｰﾁﾝの深い所でｴﾗｰが発生すると､大域ｼﾞｬﾝﾌﾟに
近いようなことをしないと処理を中断できないとか､とにかく頭を悩ませる
問題とは思います｡(品質向上のためには必要なｺｰﾄﾞではありますが)
今風に実装するなら､例外(Exception)を投げる実装がすっきいりまとまって
いいのではないか？と思います｡
ﾃｽﾄの段階では､現実から離れたﾃﾞｰﾀでもﾃｽﾄをすると思いますので必要だと思います｡
でも､実用のﾚﾍﾞﾙになってきたときに､そこまでﾌﾟﾛｸﾞﾗﾑの中でﾁｪｯｸをする必要があるかどうかは､その関数がどのくらいﾌﾟﾛｸﾞﾗﾑの中で重要なﾎﾟｼﾞｼｮﾝだったり､ｲﾚｷﾞｭﾗｰなﾃﾞｰﾀが来る可能性が高いかによると思います｡
ﾃｽﾄを繰り返して､ほぼ問題なく稼動しているのであれば､何か問題が起きたときにすぐにﾁｪｯｸできる手法で行われていれば､ﾁｪｯｸはいらないと思いますよ｡
なるほど｡至極もっともな考えだと思います｡ただ､一般論の域を出ていないもどかしさも感じます｡こちらの質問もひじょｰに抽象的な書き方をしているので､どうしても突っ込んだ意見になりにくいのは､仕方がないですかね｡
私の個人的な考え､やり方ですが､関数が意味のある値を返すなら全てﾁｪｯｸするｺｰﾄﾞを書きます｡でないと次に何が起こるか予測がつかないと思うので｡あとは運用中に不具合が発生したとき､ｴﾗｰﾄﾗｯﾌﾟをｶｯﾁﾘやってﾛｸﾞなりなんなり残さないと後で原因分析できなくなるのが恐ろしいです｡
結局のところ､その関数の結果値を判断していないﾓﾉに対してどの程度の信頼性が求められているのか？ という､その信頼性の高低によって答えは変わってしまうんですよね｡
非常に大雑把にあいまいな表現で説明すると､ﾓﾉは高信頼性が要求されるｼｽﾃﾑの一部です｡作ってくれている人には少なくないお金を払っているし､これを安くないお値段でお客様に買っていただく｡そｰゆｰ状況で考えたとき､ちょっと困ってしまうわけです｡
ﾒﾓﾘｱｸｾｽ違反(ﾎﾟｲﾝﾀの戻り値がNULL)でｵﾁるのは恥ずかしいし
他の処理(関数)でも､どこが発生原因かわからないのは､不具合調査で自分の労力が増すばかり｡
PGの誤りだけではなくて､動作環境や渡される引数､入力ﾌｧｲﾙが原因の場合にも処理異常の理由を追えますから｡(むしろ､ﾘﾘｰｽ後は､この用途のほうが多いかも)
どの関数(必要なら呼び出し時引数の値も)で､どういった想定外あるいはｴﾗｰ応答があったか､必要に応じてﾛｸﾞにも吐き出すようにしています｡
自前でｴﾗｰﾊﾝﾄﾞﾙ用(ｴﾗｰだけでなくﾁｪｯｸﾎﾟｲﾝﾄのﾛｸﾞ出力､呼び出し履歴の記録なども)ｸﾗｽを用意しておくと､使いまわしができて楽ですよ｡
ただ､ｴﾗｰ処理ｸﾗｽのｴﾗｰをこのｸﾗｽ自身でﾊﾝﾄﾞﾙすると無限ﾙｰﾌﾟ(ひいてはｽﾀｯｸ領域枯渇)につながるのでそこだけ注意です｡
そもそも質問のｺｰﾄﾞが何の言語かにもよるのですが…｡
自分は基本は過剰にならないように､必要な部分だけﾁｪｯｸを行うﾀｲﾌﾟです｡
仕事では組み込みが多いのでCが中心です｡
printf()とかならまずﾁｪｯｸはしないし､malloc()系(というかﾒﾓﾘ系)の関数ならばﾁｪｯｸは必須ですし｡
当然､自分の作った関数でもすべてﾁｪｯｸしています｡
逆に家で使っているRubyなんかだと､わざと例外には対処せずにｴﾗｰを生のままで出すようにしています｡
まあ理由としては､被害が少ないというのも有りますが言語側のｴﾗｰを生で見たいので｡
個人的にはこのほうがﾊﾞｸﾞがあっても修正がしやすいです｡
また簡単な動作を見るためのﾃｽﾄﾌﾟﾛｸﾞﾗﾑならばｴﾗｰﾁｪｯｸはほとんどしません｡
ただし､ﾃｽﾄﾌﾟﾛｸﾞﾗﾑでもﾄﾞﾗｲﾊﾞの動作をﾁｪｯｸするﾕｰｻﾞﾗﾝﾄﾞ側のﾌﾟﾛｸﾞﾗﾑだとｴﾗｰﾁｪｯｸはしっかり行います｡
どんなｼｽﾃﾑ開発でも､それが仕事なら､単体ﾃｽﾄで戻り値のﾁｪｯｸはしますよ｡たとえ､99.9％のｹｰｽが正常系で動いており､ｴﾗｰ戻り値の影響を受けることは皆無だったとしても､関数仕様書に書いてあることはすべて単体ﾃｽﾄします｡
私がﾌﾟﾛｼﾞｪｸﾄﾏﾈｰｼﾞｬだったら､単体ﾃｽﾄ結果報告書が出ていない関数を結合することはさせません｡
＞一般論の域を出ていないもどかしさも感じます
そうですね｡すみません｡(会社でも突っ込みが甘いと言われたり､､)
もう少しﾌｫﾛｰのﾘﾌﾟﾗｲ書きます｡
大昔､すこしまともなｿﾌﾄを組んだ頃は､
ﾁｰﾑ全体で､ｴﾗｰﾊﾝﾄﾞﾘﾝｸﾞのﾙｰﾙも決めて
統一的に処理していました｡(開発者が都度判断していると
異常時の動作が開発者間で不統一になるし､ﾏﾆｭｱﾙに
ｴﾗｰｺｰﾄﾞを掲載する必要があるので)
まったくもって同意見… なんですが､私のいる世界は果てしなく醜く､ﾄﾗｯﾌﾟされないｴﾗｰが山のようにあります｡品質というのは常に時間(＝ｺｽﾄ)とのﾄﾚｰﾄﾞｵﾌで､かけたｺｽﾄに見合った品質のものしか出来上がってこない｡まあ､もっとｺｽﾄを投入すれば､id:pahooさんのように作れるんでしょう｡今ﾌﾟﾛｸﾞﾗﾑ製造をお願いしている所にいくらお支払しているのか私は知りえる立場にはないんですが､ものすごく値切った結果として｢結果値を判断しない｣という事につながったのかもしれません｡
でも製造でｹﾁってしまったら､節約した額の数倍の額が不具合対応で消えると思うんですけどね｡そこを冷静に見積もれば､製造の時点でもっとｺｽﾄかけないと(品質を上げないと)保守で結局損をすると､ｻｲﾌを持っている人たちを説得することができるかもしれません｡
あとはまあ､これはあんまり言っちゃいけないのかもしれないけど､ﾌﾟﾛｸﾞﾗﾏとしての気概というか､心意気､美意識に負う部分も個人の資質として持っていないと､より完璧に近い結果値判断はできないのかもしれません｡
＞自分は基本は過剰にならないように､必要な部分だけﾁｪｯｸを行うﾀｲﾌﾟです｡
現実的な落とし所として､まあ､そうするしかないよね？という共感を覚えます｡結局ﾌﾟﾛｸﾞﾗﾑの中で100回関数を呼び出してそれぞれ個別にﾁｪｯｸをやっていたら大変なｺｽﾄがかかる｡ﾁｪｯｸをまとめられるような実装上の工夫ができれば､それで実務上十分だと思います｡個人の感覚として｢満足｣はできないけど､｢納得｣はできる､そんな感覚です｡
あとはﾌﾟﾛｸﾞﾗﾑの用途でﾁｪｯｸの度合を変えるのもごもっとも｡ｺﾝｾﾌﾟﾄを実証するだけのﾃﾞﾓﾌﾟﾛｸﾞﾗﾑなら､正常ｹｰｽだけが網羅されていれば十分ですね｡
あと言語に関してですが､実務上｢関数の結果値｣という概念がｻﾎﾟｰﾄされている言語であれば同じ悩みがある､と考えています｡なので､いろんな人のいろんな考えがききたいなあと｡
自分が作ったｼｽﾃﾑを自分自身が使うとしたら――私は､いつも､そう考えて仕事をしています｡
たしかに､ﾃｽﾄ工数はｺｽﾄとのﾄﾚｰﾄﾞｵﾌですが､単体ﾃｽﾄを全くやらないようなﾌﾟﾛｼﾞｪｸﾄは欠陥品を産み出すだけです｡単体ﾃｽﾄを無視してお客様に欠陥品を納品する仕事なら､最初からやらない方がいい(ｷｯﾊﾟﾘ)｡
とはいえ､醜いﾌﾟﾛｼﾞｪｸﾄは少なくないですよね｡正常化できればいいんですが､ｺｽﾄが全然見合わなくて､ﾌﾟﾛｼﾞｪｸﾄを止めなければならないことがあります｡
C標準関数に対して考えるならば､fopenのように外的要因によりｴﾗｰとなる可能性のあるものと､memcpyのように外的要因の無いものとに分けられると思います｡
前者でのｴﾗｰはｴﾗｰ処理が必要｡
後者でのｴﾗｰはﾊﾞｸﾞでしか起こりえないためｴﾗｰ処理は不要です｡
しかし､前者でのｴﾗｰは正常動作中に十分起こり得るので､そのｴﾗｰ処理自体が正常処理の一種でありこれが無いのは欠陥と考えられます｡
外的要因を検討し､それに対する処理さえ行えばｴﾗｰ処理は全く必要無いと考えられます｡
標準関数ではなく､自作の関数に対して考える場合は､話は全く逆になります｡
考えるべきは､もし戻り値がｴﾗｰだった場合に､他への影響が有るか無いかです｡
例えば､ﾛｸﾞ出力用の自作関数がｴﾗｰとなった場合､ﾛｸﾞが出力されないだけでﾌﾟﾛｸﾞﾗﾑ本来の動作には全く影響しないためｴﾗｰ処理はいらないです｡
影響があると考えた場合は､きちんとしたｴﾗｰ処理が必要です｡
そのｴﾗｰをﾘｶﾊﾞﾘｰするｺｰﾄﾞを記述するわけですが､ﾘｶﾊﾞﾘｰできない場合は､ﾌﾟﾛｸﾞﾗﾑを停止するなどのｺｰﾄﾞを記述する場合もあります｡
ではﾊﾞｸﾞ対策はどうするか？
単体ﾃｽﾄである程度潰したとしてもﾊﾞｸﾞは必ず残ります｡
よって､何処まで正常に動作したか､どこからおかしくなったかを事後に確認できるよう､ﾎﾟｲﾝﾄ､ﾎﾟｲﾝﾄで動作情報のﾛｸﾞを出力するように作るのがいいと考えています｡
余談ですが､上記の単体ﾃｽﾄの『ある程度』とは､試験員が『完璧です』と報告するﾚﾍﾞﾙを言っています｡
よく『ﾃｽﾄ結果が完璧なんて有り得ません』(正論)という人がいますが､その場合､どの辺りが不安かを尋ねると完璧じゃない理由がぼろぼろ出てきます｡
つまり､ちゃんとﾃｽﾄしてないってことです｡
単体ﾃｽﾄとしてやるべきことを全て行い不安が無くなれば『完璧』と言えるはずであり､これが品質を決めると私は考えています｡
ｴﾗｰ処理とは､ちゃんとﾃｽﾄするのが前提にあってこそのものであり､単体ﾃｽﾄ不足を補うためのものでは無いと考えています｡
非常にﾎﾞﾘｭｰﾑのある内容ありがとうございます！
ほかのｴﾝﾄﾘも読んでなんとなく思うことですが､全てはどこまでうまくいかなかった原因を追い詰めるか､そのﾎﾟﾘｼｰ次第で､結果値判断(ｴﾗｰﾄﾗｯﾌﾟ)をどの程度の粒度でやるかが決まるな､と感じます｡
たとえば､私の感じだとid:tezuboaさんの
C標準関数に対して考えるならば､fopenのように外的要因によりｴﾗｰとなる可能性のあるものと､memcpyのように外的要因の無いものとに分けられると思います｡
前者でのｴﾗｰはｴﾗｰ処理が必要｡
後者でのｴﾗｰはﾊﾞｸﾞでしか起こりえないためｴﾗｰ処理は不要です｡
というのは大いに違和感を感じるところです｡どんな関数でも､必要だから呼び出しているわけで､呼び出した結果が期待通りでなかったら､後続処理は続けられない｡連鎖的にｴﾗｰが生じるか､一見うまく言っているようで実は本来の期待結果と異なるものが最終的な出力として得られる｢誤動作｣ということになる｡
でも
影響があると考えた場合は､きちんとしたｴﾗｰ処理が必要です｡
そのｴﾗｰをﾘｶﾊﾞﾘｰするｺｰﾄﾞを記述するわけですが､ﾘｶﾊﾞﾘｰできない場合は､ﾌﾟﾛｸﾞﾗﾑを停止するなどのｺｰﾄﾞを記述する場合もあります｡
ではﾊﾞｸﾞ対策はどうするか？
単体ﾃｽﾄである程度潰したとしてもﾊﾞｸﾞは必ず残ります｡
よって､何処まで正常に動作したか､どこからおかしくなったかを事後に確認できるよう､ﾎﾟｲﾝﾄ､ﾎﾟｲﾝﾄで動作情報のﾛｸﾞを出力するように作るのがいいと考えています｡
こｰゆｰ､意味のある結果が得られる単位､ﾘｶﾊﾞﾘｰﾎﾟｲﾝﾄを考慮したﾎﾟｲﾝﾄで一括してｴﾗｰの有無をﾁｪｯｸすればいい､という考えですね｡これは私も賛成です｡
ｴﾗｰ処理とは､ちゃんとﾃｽﾄするのが前提にあってこそのものであり､単体ﾃｽﾄ不足を補うためのものでは無いと考えています｡
そこは多分memcpy関数に代表される信頼性の高い枯れた関数がｴﾗｰ値を出すのは単体ﾃｽﾄにおいてだけでそこでﾊﾞｸﾞを摘出しきれる！しきるべき！という考えですかね｡
でもここはちょっと違うと思うんですよ｡ﾃｽﾄは不具合＝要件と違う動作をするかどうかを検査するもので､ｴﾗｰ処理は要件そのものです｡要件なんだから､ｴﾗｰ処理だって単体ﾃｽﾄするんですよ｡
他のｴﾝﾄﾘでも書きましたが､｢ﾌﾟﾛｸﾞﾗﾏとしての気概｣と後で苦労したくないという実利が原動力ですね｡実利がﾁｪｯｸを実装するという行為に結びつくには､当事者であるという認識がないといけない｡作っている人の立場や気持ちが､仕様やｺｰﾄﾞにあらわれてくる｡ｺｰﾄﾞを延々と見ていますが､やっぱりその人がそのｺｰﾄﾞを書いている時の気持ちみたいなものは､感じられるような気がしますね｡気のせいかもしれませんがw
自前でｴﾗｰﾊﾝﾄﾞﾙ用(ｴﾗｰだけでなくﾁｪｯｸﾎﾟｲﾝﾄのﾛｸﾞ出力､呼び出し履歴の記録なども)ｸﾗｽを用意しておくと､使いまわしができて楽ですよ｡
ここはね､お手本を用意して｢こうやってやればﾗｸですからﾏﾈしてください｡｣といってお願いすれば､みんながやってくれるようになる｡と甘い期待をしています｡個人でｽｷﾙある人は､自前の便利ｺｰﾄﾞの断片をいっぱいもっているし､それがその人のｽｷﾙだと思う｡なので､そｰゆｰ努力をしない人にまでため込んできたﾅﾚｯｼﾞを開示するのは､抵抗があるかもしれない｡でもｿﾚをしないと組織としてｽｷﾙｱｯﾌﾟにつながらない… すいません､このへんは私の自問自答です｡
でも､気概も持たず､工夫もしない人にやってもらうようにするにはどうしたらいいのか？ というのは､ﾅﾚｯｼﾞ開示よりも難しい問題かもしれません｡
memcpy()のmanﾍﾟｰｼﾞを見ていただければ分かりますが､戻り値は有りますが､ｴﾗｰかどうかは分かりませんのでｴﾗｰﾁｪｯｸは必要有りません(というかﾁｪｯｸしようがないです)｡
このような場合の自分の対処方法ですが､
memcpy()に限らず標準関数で戻り値以外のﾁｪｯｸを行いたい場合は､関数をﾌｯｸして自作の関数を呼び､この自作した関数ないで引数のﾁｪｯｸ等を行うようにしています｡
これでmemcpy()で書き込み不可能なﾒﾓﾘを指定されるなどしても問題はありません｡
あと関数の戻り値以外でも以外でもﾁｪｯｸするべき箇所としては､0除算とか色々有ります｡
元々の質問の関数ﾁｪｯｸが9割方無いと言う状況では他にも問題は多数有りそうなのが心配ですね｡
ｺﾒﾝﾄありがとうございます｡
長文なので読んでもらえないのではと心配してました｡
まず､お詫びとして､memcpyを例にしたのはﾒﾓﾘｰ破壊の代表であり､皆がきらう関数No1だろうという理由からでした｡
id:longicornさんの仰る通りmemcpyはvoid型であり､例としては不適切だったかもしれません｡
『memcpyのｴﾗｰ』＝『期待通りのｺﾋﾟｰが行われない』と読み替えて頂ければと思います｡
さて､私とid:Rintaさんとでお互いに単体ﾃｽﾄの定義(ﾌｪｰｽﾞ)が食い違っているのかもしれませんね｡
私の考える単体ﾃｽﾄの主なﾎﾟｲﾝﾄは以下です｡
･1ﾗｲﾝ毎に､意図した動作をするか確認する｡
･ﾛｼﾞｯｸ上取りうる入力値全てでの動作を確認する｡
(それ以降のﾃｽﾄは結合／総合ﾃｽﾄﾌｪｰｽﾞとなります)
それを前提で考えると､単体ﾃｽﾄを行ったのにも関わらずmemcpyでｴﾗｰ(＝期待通りのｺﾋﾟｰが行われない)となるようなｺｰﾄﾞは作成できないと考えています｡
ｴﾗｰとするには､memcpyに渡す値がおかしいことしか考えられなく､これは､memcpyを呼び出す前のｺｰﾄﾞに問題がある､つまりはﾃｽﾄ漏れと考えられます｡
＞ｴﾗｰ処理は要件そのものです｡
呼び出す前のﾁｪｯｸ処理もｴﾗｰ処理の1つだとのお考えならid:Rintaさんの意見に大賛成です｡
ただ､自前の関数の場合は､呼び出す前にﾁｪｯｸしても期待通りの動作をするとは限らないので呼出し後のﾁｪｯｸも必要と考えます｡
(その時点では良くても1年後に関数が改造されて意図しない動作となる可能性が大いにあるという意味です)
また､id:longicornさんの言うように1枚被せるのも有効だとは思います｡が､将来改造される危険性が増える点は注意が必要だと思います｡
呼び出し後のｴﾗｰ処理については､過度のｴﾗｰ処理､意味の無いｴﾗｰ処理かどうかの見極めが大変なので､C標準関数は信用し､自前の関数は信用しないと考えるとﾎﾟﾘｼｰ的にもすっきりするような気がします｡
どうでしょうか？(また長文ですみません)
ですが､ｴﾗｰの状況によりしないで済ませることもあります｡
また､質問のような状況(90%ほど､つまりほとんどがｴﾗｰ処理していない)で､ｴﾗｰが発生した場合に
致命的なことが起こるようならば､ｴﾗｰを返す関数側でｴﾗｰ処理(ﾛｸﾞ吐いて終わっちゃうとか)することもあります｡
また､ｴﾗｰのﾊﾝﾄﾞﾘﾝｸﾞを入れたﾗｯﾊﾟｰ関数を書いて､まとめてﾗｯﾊﾟｰ関数を使うように修正しちゃうこともあります｡
今回の質問では､
>｢開発途上のﾌﾟﾛｸﾞﾗﾑの品質が心配なので検査して欲しい｣という依頼を受け･･･
>
と言うことなので､どういう方法かでｴﾗｰ処理を入れておかないと後のにﾄﾗﾌﾞﾙに発展しそうな予感がしますので､時間が許すならなにがしかの手段を講じておくのが吉だと思います｡
具体的な開発言語の表記がないので違うかもしれませんが､
｢正常に処理を完了できたか､何らかのｴﾗｰが発生したかを整数型の値で返す関数｣
という内容から単純に推測すると､
何らかの処理(ﾌｧﾝｸｼｮﾝ)でｴﾗｰが発生したときに｢そのｴﾗｰ内容に応じてｴﾗｰｺｰﾄﾞを返す処理｣を各ﾌｧﾝｸｼｮﾝ内に記入しており､それが殆どのｴﾗｰｹｰｽに対して未ﾁｪｯｸだという事ではないですか？(VBのように)
(VBを例にとると)
通常､定義済み関数やﾌﾟﾛｸﾞﾗﾑ自身が返すｴﾗｰｺｰﾄﾞ自体は､当然ﾁｪｯｸする必要はありませんが､そのｴﾗｰ(ｺｰﾄﾞ)によって､どういう処理を行うか？つまり､
･どういうｺﾒﾝﾄを表示するか？
･処理を中止する／そのまま継続する？
･何か特別なﾌｧﾝｸｼｮﾝを実行する？
は､ﾌﾟﾛｸﾞﾗﾏｰが仕様に基づき(重要度が低い未定義ｹｰｽは個人的裁量)で決めるので､まず､その仕様を確認するのが先決ではないでしょうか？
仕様が決まっていれば､当然それに基づきﾁｪｯｸを行います｡ただし､100ﾌｧﾝｸｼｮﾝあっても､通常は共通で使用できるﾛｼﾞｯｸもあるので､全部は必要ないはずです｡
あと､｢未ﾁｪｯｸのまま正常処理を続行｣の状態ですが､ﾌｧﾝｸｼｮﾝ内にｴﾗｰが無ければ当然未ﾁｪｯｸというか､ｴﾗｰ処理は行われませんが､そのことを指しているのか､ｴﾗｰが生じていても引っかからないということでしょうか？
前者をﾁｪｯｸするなら､色々なｹｰｽを想定してﾃｽﾄﾃﾞｰﾀを作成し､ｴﾗｰを発生させたときに意図どおりにｴﾗｰ処理がされるかをﾁｪｯｸします｡(通常ﾃｽﾄ仕様に基づく)
後者の場合は､そのﾌｧﾝｸｼｮﾝでどういうｴﾗｰが生じたときが致命的(計算結果が異なるとか､動作に障害が生じるとか)かを把握した上で､最低限､その対応は行いﾁｪｯｸします｡それ以外は､よく生じるｹｰｽがわかっていればその分を追加し｡あとは余裕のある範囲内でﾁｪｯｸするのが通常です｡
気になるのは｢開発途上｣ということなので､全体が完成したときに､どこがどういう影響を及ぼすかが不安です｡結合ﾃｽﾄもやるのでしょうが､最低限､各ﾌｧﾝｸｼｮﾝおよびﾓｼﾞｭｰﾙ単体ﾚﾍﾞﾙで､動作障害のﾁｪｯｸとｴﾗｰ発生時の適切な処理が行われているかということでしょうか｡
基本的なことですが､参考になればよいのですが｡
だいたいﾌﾟﾛｸﾞﾗﾑ規模の2/3はｴﾗｰ処理になるとおもっております｡
戻り値の判定が無い場合､確かにｺｰﾃﾞｨﾝｸﾞや単体ﾃｽﾄ等の工数は減りますが､
後工程で戻り値を見ていない関数で問題が発生した場合､問題解析が困難になります｡
その場合や発生頻度の低い場合とう原因の追究に時間がかかり結局のところ
上位工程楽した分苦労し顧客からの信用度も低下してしまいます｡｡ちなみに実体験です｡｡
単体試験環境と結合試験環境が違い場合等もあるので単体でうまくいっていても
結合で問題が発生する場合がよくあります｡
ｺｰﾃﾞｨﾝｸﾞ+単体ﾃｽﾄの工数 < 以降のﾃｽﾄや運用での解析工数と
思います｡
