Dynamic Test Runner 0.0.2
http://shinh.skr.jp/binary/dtr-0.0.2.tar.gz
.o ファイルをダイナミックロードして中のテストを駆動するものです。
http://d.hatena.ne.jp/shinichiro_h/20051123#1132700485
の続き。ローダっぽいもの書くのは案外楽しいのでしばらく地道になんかしようと思います。
- -c オプションで落ちる時は落ちるように (要は core 吐かせたい時)
- 落ちた時にテスト内のスタックトレースを表示 (make fail で見れます)
- Objective-C のテストが動くように (そのために .ctors セクション対応した)
あとはなんか色々した気がするけど思い出せない。
うまくいってないところメモ。
- AMD64 ではなんか標準ライブラリが呼べてない。再配置は正しく見えるんだけど、 callq ってなんか意味違うんかな。 q は quad だと思うんだが。インストラクション見るべし。
- D 対応ができないのは gc_init が何故かコケるから。 malloc した領域に書き込む部分がうまくいってない気がする。
- GCJ は .jcr セクションを _Jv_RegisterClasses に叩き込めばいいように見えたけどまだなんか初期化処理足りんのかな。
- コア吐く時にその吐いたコアを再配置するとかっこ良くないか。(現状 .o 内で吐いたコアは中身が見れない)
やってないことメモ。
雑記
トラバできてた .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 より小さい標準ライブラリがあると嬉しいんだけど。
追記: 話それすぎ。最初の言及元見て思ったのはテストと言えば統計だ、ということだった。つまりあれです、テストが終わったら
総ステップ数: 12345 OP TIMES CLOCKS mov 2345 ... jmp 1234 ... ...
とか出るわけだ。ていうか gcov でいいか。
そういえば gcov も専用コンパイルオプションつけなくても実装できる気がするんだけどパフォーマンスの問題かな。
