これは「Friendly Advent Calendar 2014」の記事です。
昨日の続きです。
デグレの恐怖を克服したい！ってとこまで書きましたね。
キャプチャリプレイ
そして、若き日の僕は、システムテストを自動化し始めました。
やっぱり、最初はキャプチャリプレイもやりました。
でも、すぐにやめました。
理由は・・・
①タイミング依存での失敗が多い
②遅い
③すぐに壊れる
まあ、もちろん最初だから使う側も色々スキル低くてツール使いこなせてなかったというのもあると思います。とは言え、その後色々な人の話聞いても同じような感想が多かったですね。
で、色々調べて分かったんですけど、キー、マウスエミュレートでは求める確実性を出すのは並大抵のことではないということです。だって、キー、マウスのエミュレートはOSに命令送ってるんですよね。
その後、そこからアクティブなアプリに指令が行く。
指令送る側はOSに届いたとこは確認できるけど、目的のアプリまで届いたかは確認できないんです。
さらに、そのアプリで目的の処理が終わっているか判断するとか大変ですよね。
組み込み型の俺々フレームワーク
で、どうしたかというとですね。
俺々テストフレームワーク作成に行っちゃいます。
今考えると、凄い頑張ってましたね。
・テスト記述言語
・結果判定の仕組み
・レポート機能
これを、それぞれのプロダクトに組み込んで、それにテストスクリプトを読み込ませて実行させるのです。
WindowAPI的なものも実装して、GUIも操作できるようにもしましたし、もちろんその他テスト用のAPIも呼び出せるようにしてました。
(考え方は既にFriendlyなんですけどね。)
後で読んだんですけど、「アジャイルソフトウェア開発の奥義」にも似たような考えが書かれてました。（ちょっと違いますけどね。）まあ、筋は悪くなかったわけです。これは頑張った甲斐があって、結構役に立ちました。
同期がとれる！
何より嬉しいのは、処理の同期がとれることですね。
書いた順番で確実に処理してくれる。
これはテストには欠かせないことです。
それに、同期がとれると、遠慮なく次の処理を実行させられるので、結果高速に動作するのです。
安定した動作を実現
結局ですね、プログラムっていろんな書き方ができるんですね。
クリックに対する反応の書き方、キーの判別の仕方、メッセージの取得方法、フォーカス処理、メッセージの先送り、etc...。
これらに対していくつもの解があって、それぞれの手法ごとに癖があるのです。
だから、外から見て同じように見えたからと言って同じように操作できるとは限らないのです。
処理を内部に組み込むことによって、自然とホワイトボックス的な視点で対象を見るようになり、それぞれに適した解を与えるようになっていました。頭がホワイトボックスにプログラムを見るモードになっていれば、これらには対応していけることが分かりました。だって僕たちは、そのシステム作っている人間なんですからね。
普通のプログラムと同じノリでテストフレームワークを拡張できる
これは思っていたより衝撃でした。プロダクトにフレームワークを埋め込む方式でやってたので、そのフレームワークからは普通のプログラムと同じようにプロセスを操作できるのですね。まあ当たり前と言えば当たり前なのですが。
外部ツールに頼っていたころは、どうしても限界がありましたが、この手法だとそれがないのです。
最適な自動化スコープを発見
ホワイトボックスに見たことと、あと言語が非力だったせいで、どうしても省エネなテストを考えるようになったんですね。おかげで、気づきました。
困っていたデグレはGUI層で発生するより、もっと内部の結合で発生することが多いということです。そして、GUI層のデグレは実はそれほどリスクが高くなくて、内部の結合の方がリスクが高いのです。
だから、システムを結合させて、ホワイトボックス的にリスクの高い部分を狙い撃ちにするようなテストが書けるこの方法は非常に効果があったのです。
そんなのコンポーネントテスト書けよって思うでしょ？でも、大規模な結合のコンポーネントテスト書くのも難しいんですよ。
特にこの時代は、シングルトンにも正義があった時代です。
それを拡大解釈したstaticな結びつきが強いコードが、そこら中で量産されていましたよね？アプリを起動しなければ、内部的な結合検査もままならなかったのです。
まあ、今でも大規模な結合部分はこの方法が役に立っています。
問題点
しかし、もちろん問題はありました。
1.プロダクトが不正終了するとテストが全部止まる。
(場合によってはレポートも残らない）
2.言語が弱い(DSLと言えば聞こえはいいけど、しょせん俺々スクリプトだもの)
3.開発環境はもっと弱い。
4.スクリプトからプロダクトを操作するAPIのメンテにコストが結構かかっている
4.学習コストが高すぎる
5.複数のプロダクトへの展開にもコストがかかる
なんとか、ならないでしょうか？
実はC#(.Net)が解決へと導くのでした。
明日に続く・・・
