Friendly誕生！ - ささいなことですが。

これは「Friendly Advent Calendar 2014 - Qiita」の記事です。

昨日は、「俺々フレームワーク作って結構役に立ったけど、問題もあるよなー」ってとこまで書きました。

メリットと問題

色々書きましたが、俺々フレームワークのメリットって何に起因していたかというと
・好きなように内部メソッド呼べる

問題は以下のことに起因していました。
・対象プロセスにフレームワークごと組み込んでいる
・テストスクリプトが独自言語
f:id:ishikawa-tatsuya:20141203000848p:plain

問題対応

どうすれば良いかというと、やっぱり余計なものはプロセスから出せよということですよね。
実はスクリプトは最後は結構豪華になって、拡張C言語的なものになっていました。
例えばこんな感じに書けてました。

//データファイル読み込み
var files = ReadAllLine();

for (var i = 0; i < files.Length; i++) {
	//プロジェクトにファイルを読ませる
	var path = files[i];
	Api_ProjectLoadFile(path);
}

実はですね。このスクリプトの中で対象プロセスに実行させたい処理って
Api_ProjectLoadFiles(path);
だけなんですよね。
後は、どこでやっても良い。
むしろ対象プロセスにやらせたくない。
こうやれたらいい。
f:id:ishikawa-tatsuya:20141203001924p:plain

こうできたら、テストスクリプト自体は別のプロセスで動作するのでテストフレームワークも既存のものを使えます。
NUnitとかVSTestですね。

それと、Api_ProjectLoadFileにしても、わざわざスクリプト側に公開しているんですけど、これ面倒です。
(まあホストに取り付く系のスクリプトはこうするしかないんですけどね。Luaとか。)
ベストは普段プログラムで使っているAPIがそのまま使えたらいい。
まあ、何か書かなければならなくても、特殊構文でなく既知の構文であったらいい。
（学習コスト的に）
f:id:ishikawa-tatsuya:20141203001921p:plain

でも、普通に考えてそんなの無理ですよねー。
だって、プロセスの壁があって、メモリもプログラムも完全に別けられています。
関数呼び出しどころか、文字列だっておいそれと受け渡しできません。
f:id:ishikawa-tatsuya:20141203002227p:plain

閃き来たる

しかし！
いくつかのヒラメキがあり、この問題を全て解消したのでした！
(閃きの内容は長いので省略、また別の日に、この辺の技術もちょっとづつ書きます)
閃いてから、実際に作り出すまでちょっと間があったんですけどね・・・。
だって、昼の仕事終わった後、ちょっと作るにしては結構なボリュームだったんだもの。

そして、プロセス越しに好きなAPIを呼び出せる魔法のライブラリが誕生しました。
しかも、インターフェイスを.Netで作ったので、テストスクリプトをC#で書けるのですよ！
これは非常に強力ですね。
.Netのライブラリをフルに使えるのはもちろん多彩な実装、設計技術を使えます。
もちろんVisualStudioも使えるのです。
これは保守性の高いテストコードを構築できそうですよね。
それから、このライブラリは「別プロセスの操作」のみに注力しています。
つまり、レポート機能などテストフレームワークとしての機能は別のものに委譲しているのです。
なので、その辺りも既存のNUnitやVSTestなど馴染みのあるものを使えるわけです。
f:id:ishikawa-tatsuya:20141203001922p:plain