tag:blogger.com,1999:blog-1887782251735454807.post177857451641796015..comments2024-03-18T14:18:20.287+09:00Comments on ブログズミ: [C++] Private な関数のテストsrz_zumixhttp://www.blogger.com/profile/12777270094814249170noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1887782251735454807.post-4246657344247656642019-03-01T11:58:49.334+09:002019-03-01T11:58:49.334+09:00×やむおえない
○やむをえない(やむを得ない、止むを得ない)
反論、批判的な回答をする場合こそ、言...×やむおえない<br />○やむをえない(やむを得ない、止むを得ない)<br /><br />反論、批判的な回答をする場合こそ、言葉には気を付けましょう。<br />また、訂正するときにも、気を付けましょう。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1887782251735454807.post-43556502470456529902018-10-29T21:11:33.129+09:002018-10-29T21:11:33.129+09:00訂正します。
×google testの開発元もやむおえない限り非推奨としています。
○google...訂正します。<br />×google testの開発元もやむおえない限り非推奨としています。<br />○google testの開発元もやむおえない限ってで、基本的に非推奨としています。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1887782251735454807.post-63879912591076354212018-10-29T20:43:12.652+09:002018-10-29T20:43:12.652+09:00http://opencv.jp/googletestdocs/advancedguide.html...http://opencv.jp/googletestdocs/advancedguide.html#adv-testing-private-code<br />>ソフトの内部的実装を変更しても,ユーザからその変更が見えない限りは,テストは失敗するべきではありません.よって, ブラックボックステ><br />ストの原則 に従い,大部分のコードテストは public インタフェースを使って行われるべきです.<br />>もし,まだ内部的な実装コードをテストする必要があるならば,そうしなくてもよい設計がないかどうか考えてください.しかし,どうしても pub<br />lic ではないインタフェースを通してテストを行わなければならない場合は,そうすることもできます.2つの場合を考えてみましょう:<br /><br />できるからしていいという問題ではありません。<br />できるからしていいのであれば、reinterpret_castでオブジェクトの中身を<br />操作することだって可能なのだから良いという話になります。 <br />本来の目的に沿い効果的に開発するのであれば、試験すべきではありません。<br />google testの開発元もやむおえない限り非推奨としています。<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1887782251735454807.post-89586008054957478022017-12-28T14:17:56.661+09:002017-12-28T14:17:56.661+09:00>そもそもオブジェクトのI/Fではないものを単体試験の対象にすべきじゃありませんよ。
そんな訳...>そもそもオブジェクトのI/Fではないものを単体試験の対象にすべきじゃありませんよ。<br />そんな訳ありません。必要があるからマクロ定義されているんです。<br />妥当性は個別に判断すれば良いことです。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1887782251735454807.post-11129804860154376272017-05-15T16:01:18.522+09:002017-05-15T16:01:18.522+09:00コメントありがとうございます。
ご指摘のとおり、private メンバーをテストするのは良い状態では...コメントありがとうございます。<br />ご指摘のとおり、private メンバーをテストするのは良い状態ではないと思います。<br />(実際、自分でも書くことはほとんどないですね。)<br /><br />本記事では良し悪しは別として、テスティングフレームワークではそのようなケースにも対応しており、その機能の紹介をする意図でした。<br />なので、ガンガン private メンバーのテストもしていこうぜ!と推奨しているわけでじゃないです。<br />ただ、ちょっと説明不足でしたね。すみません。<br />srz_zumixhttps://www.blogger.com/profile/12777270094814249170noreply@blogger.comtag:blogger.com,1999:blog-1887782251735454807.post-68141994268347332062017-05-04T22:41:57.893+09:002017-05-04T22:41:57.893+09:00そもそもオブジェクトのI/Fではないものを単体試験の対象にすべきじゃありませんよ。
xUnitでせっ...そもそもオブジェクトのI/Fではないものを単体試験の対象にすべきじゃありませんよ。<br />xUnitでせっかく可能になったリファクタリングができなくなります。<br />例えばprivate関数の条件を全て網羅できたからといって、private関数を呼び出しているpublic関数をprivate関数分だけ省略したとしましょう。private関数の実装を呼び出し元のpublic関数が吸収すればもう試験ケースは使えなくなってしまいます。Anonymousnoreply@blogger.com