トラバできてた .so からロード && スケルトンをスクリプトで生成なアプローチのもの (http://nikki.hio.jp/?date=20051124#p01) をながめつつ。

結局どっから情報を持ってくるかって、いう話で、最悪の場合は、人間が手動でテスト登録ルーチンを書くことになるわけ。それよりマシなアプローチとして私が今まで取ってきた方法としては、

• Perl でテスト生成 (コード生成はPerlに限りますね！)
• Perl で .cc や .h ファイルからテストスケルトン生成 (.cc も .h から生成してたけど…)
• マクロ (CppUnit とかはこっちの方向性でいくらかラクにしてる)

などと結局テストコードを生成する方向性なわけだけど、別にその方向性は悪くないんじゃないかとか。例えば LangScan でソース全部なめて、hoge_test_* という関数定義を抜き出しつつ main を全て排除。抜き出してきたhoge_test_* を全て実行する main を定義してコンパイル→実行、とか。ただこれだと結局本番コードと違うものをコンパイルしなきゃいけないのが少し面倒か。あとテストのためにヘッダを増やすのですらめんどい。でもポータブルだし、安全。でも萌えない。

ソース→オブジェクト→実行ファイル、で見ると上記はソースに手を加える。オブジェクト以降を考えると、自前の crt*.o と ldscript を用意して main 完全無視でほげほげーっていうのもアリかと思った。再配置を自分で実装しなくて良いのがメリット。ただちょっとお手軽さにダメージが。

あとそれより後、 .o ファイル見るんじゃなくて実行ファイル見るっていうのも手か。再配置の時間はだいぶ減るし。ついでに .so 内のテストも実行できるようにしよう。これはすぐ実装できそうだし dtr に取り込んじゃおう。メリットは core が読めることと、 dtr のバグを踏みにくいことか。

追記: 実行ファイルの段階では不要なシンボルは消えてるからダメですね…

で、とか考えてると結局実行ファイル==ダイナミックリンクライブラリなJava はエラいとか頭をよぎって良くない。Java みたいにVM は無くていいからランタイムシステムがもうちょっと情報出してくれれば…と考えると結局Objective-C に。

Objective-C にGNUStep より小さい標準ライブラリがあると嬉しいんだけど。

追記: 話それすぎ。最初の言及元見て思ったのはテストと言えば統計だ、ということだった。つまりあれです、テストが終わったら

総ステップ数:  12345OP   TIMES  CLOCKSmov   2345     ...jmp   1234     ......

とか出るわけだ。ていうか gcov でいいか。

そういえば gcov も専用コンパイルオプションつけなくても実装できる気がするんだけどパフォーマンスの問題かな。