Entry

単体テストとかあほらしくなってやめたこととか

2010年05月04日

チーム内で TDD な開発プロセスを浸透させようと思っていて,ぼちぼち「テストは大事だよー」とか言っていたりします。ま,「少し実装したらテストする」という開発プロセス自体は,TDD とか言わなくても当たり前の話なんだけれども,やらない人が目立ってきたもんで,にんともかんとも。TDD 以前の話として,単体テストを軽視する風潮をどげんかせんといかん,とあいなったのでした。

おそらく,単体テストを通ったコードとして要求される品質が非常に高いことを踏まえないと,xUnit とか言っても馬の耳に念仏だと思う。

で,「テストは大事だよー」とか「テストを書こうねー」とか言っているわけですけれど,とあるところから,こんな話が出たのでした。

private や protected なメンバ関数はどうやってテストすればいいんですか?

たしかに。

TDD もそうなんだけれども,テストを書いて結果の正しさを「直接」保証することができるのは,public なメンバ関数だったりします。基本的にブラックボックステストなんですね。private なメンバ関数の場合,そのままではテストできません。

あたしの場合,private や protected なメンバ関数は,多めに assert を埋め込んでおくことで対応しています。大体の場合それで済むし,private や protected なメンバ関数は,(外部から使われる以上)必ず public なメンバ関数を経由することから,単体テストの範疇にも必ず含まれることになります。埋め込んだ assert は,単体テスト内でも評価される,と。

一方,これらの関数を直接 xUnit のテスト対象に含めたい場合はどうすればいいでしょう。やる必要はないんだけれども,今日はそんなことをつらつら……。で,こんなことを考えていました。

#ifdef _DEBUG
#define PRIVATE public
#else
#define PRIVATE private
#endif

あほらし……。疲れてるんだろうか。

xUnit だけではどうにもならない単体テストっつのは確かにあるわけで(ネットワークやファイルIOが絡む場合とか),ここら辺もある程度体系化しておかないとなー……とか思います。一応,書籍では『レガシーコード改善ガイド』がいい線いってるんですけれど,自分とこのワークフローとうまくすり合わせた形で,体系化できんもんかと思っていたりします。

レガシーコード改善ガイド (Object Oriented SELECTION)
マイケル・C・フェザーズ
翔泳社
売り上げランキング: 10166
おすすめ度の平均: 4.0
4 具体的で取り組みたくなりました
5 自動化テストのためのリファクタリングパターン
5 かなりの重要本
2 お暇があれば読んでもいいかも
5 経験豊富な人ほど読んで欲しい

もともと,単体テストとテストの自動化は等号で結ばれるものではなくて,「単体テストの一部を自動化できる」という意味で,前者が後者を含む関係だったりします。xUnit の運用から,両者は等号に近づいたけれども,「あくまで別物」という点を踏まえておかないと,後々ひどいしっぺ返しを食らいそうな気がします。xUnit のテスト通ったから全部オッケー!……にはならない,と。

ま,ね。多分,プログラミングの中で一番難しいと思うんですよ。テストって。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN