なんというかユニットテストは気軽に書きたいのに そのためにテストフレームワークだの覚えたりだの そのフレームワークに従うとやたらと色んなところに 関数宣言しなきゃいけなかったりだのするのは なんか本末転倒な気がします。
これはとても手軽(たぶん)なユニットテストツールです。
0.0.3 はひょっとしたら少しダメなところもあるかもしれません。
CUnit などでテストを書く場合、 なんかをインクルードしてテストスートを登録したりして、 とにかくフレームワークに従ってテストを書く必要があります。 DTR はそういった手間いらずのテストツールです。 現状 Linux でしか動作確認しておらず、 他環境ではうまく動かないかと思いますが、 比較的短期間で他環境でも動くようにできると思っています。
実際の機能は簡単な実行サンプルを見ていただくのが速いかと思います。 以下のような標準 C ライブラリの atoi をテストするコードがあったとします。
i@u ~/wrk/dtr> cat atoi.c
#include <stdlib.h>
#include <assert.h>
static void dtr_test_atoi() {
assert(atoi("1") == 1);
}
見ての通り main なども何もなく、 ただテストコードのある関数だけが書いてあります。 この関数は static でも構いません。
あとはコンパイルしてできたオブジェクトを dtr コマンドの引数にするだけです。
i@u ~/wrk/dtr> gcc -c atoi.c i@u ~/wrk/dtr> dtr atoi.o Started . Finished in 0.000000 seconds. 1 tests, 1 asserts, 0 failures, 0 errors
というように非常に簡単にテストすることができます。 配布ファイルの実行サンプルでは、
./dtr test/*.o test/*.a -lm -lz
というようにオプションを指定していますが、 このように複数テストオブジェクトを指定したり、 アーカイブファイルや共有オブジェクトも同時に指定することができます。
オブジェクトファイルをメモリ上にコピーします。 シンボル情報は libbfd を用いて読み込んでいます。 共有オブジェクトは dlopen します。
再配置情報も libbfd を用いて調べ、自力で再配置します。 この際 __assert_fail を別の dtr 内の関数に 再配置して処理を奪います。 実行する必要のあるコードには実行可能属性を付加します。
.ctors セクションにある関数は全て実行します。 dtr_test を含む全てのシンボルを 0 引数 void 返り値の関数として実行します。
assert で奪った処理に来た場合や signal が飛んだ場合は、 適切なバックトレースを出力した後に、 longjmp でもとの場所に戻ります。
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。