自己紹介
名前
石川達也 所属
株式会社 Codeer 代表取締役（兼平社員） （ http://www.codeer.co.jp/）
技術
C 、 C++ 、 C++/CLI 、 C# 、少し Java 組み込みとか、 Windows アプリとか。
趣味
ところで、
Windows
アプリ開発者の皆さん
やってません！
や
り
た
い
と
は
思
っ
て
る
ん
だ
け
ど
・
・
大きくは二種類に分かれる
部品をテスト
部品をテスト
いわゆる単体テスト、コンポーネントテスト。 クラス、メソッド、コンポーネントなど
プログラムの一部を切り出してテストを実施する。
部品をテスト
いわゆる単体テスト、コンポーネントテスト。 クラス、メソッド、コンポーネントなど
プログラムの一部を切り出してテストを実施する。
テスタビリティーが高い設計でないと、実施不可能。
ウチのレガシーコードに
部品をテスト
対応策 →
TDDBC
へ
GO
！
コード品質の改善への近道。
今日はこっちの話
部品をテスト
アプリをテスト
統合テスト、システムテスト、受け入れテスト等。
おなじみの普通にアプリ起動して、テスト項目をこなすテスト。 外部仕様を元に作れる。
これを自動化するということは、手動テストの置き換えにつながる ！
アプリをテスト
じゃあ、なんでやらないの？
・どうやっていいかわからない。 ・ツール高そうだしね。
・キャプチャリプレイツールって良い噂きかないし・・・。 ・一回やったけど、作成、メンテコストかかりすぎ。
なんで難しいの？
このタイプのテスト自動化
は
・他プロセスを操作する
・プログラム
の作成である。
プロダクトプロセス テストプロセス
この二つは別プロセス、
つまり別スレッドで動作する。
つまり、マルチスレッドプログラム。 これを忘れてはならない！
ここに、不安定さを生じさせる隙がある！ 命令
終わったかな？次の命令
あっと、まだやった。 タイミング依存で失敗。
作成が難しい
同期制御が難しい。
作成が難しい
メモリの壁がある！
作成が難しい
インターフェイスが限られている
マウス、キーは、
プログラムから操作するには相性が悪い。
タイミング依存はどうしても避けられないし。
UI オートメーション
WindowsApi
選択肢として十分あり。 ただ、ちょっと難しい。
・他プロセスを操作している
作成が難しい
そもそも、GUI アプリって、基本は人が使うもの。 プログラムから操作するには相性が悪い。
ユニットテストの場合のテスト対象は、プログラム。 あくまで上位のプログラムから使わるために存在する。 そのため、テスト自動化と相性が良い。
同期
メモリ
対応・・・
Friendly
を使う
http://www.codeer.co.jp/
Friendly は
「アプリをテスト」する テストプログラム実装用の
ライブラリ
無
料
です。
でも、なめたらダメです。
まるで、
自分のプロセスのプログラムを書くように
操作できます。
.Net 系の言語
VisualStuido の MSTest
を使ってテストシナリオを作成します。
→ それなら、既に知ってますよね？
実は Friendly を使っての操作は、
憶えることが少ないんです。
なぜなら、
使い方はみなさん既に知っているんです。
実
際
に使ってみよう！
・プロセス
間
の同期制御
・メモリの取
得
・操作用インターフェイス
大
量
の
既知
のインターフェイス。
しかも
拡張
可能。
膨大なインターフェイスが使えるようになったのは分かった。
でも、多すぎて、どれ使っていいか分からんのよね。
インテリセンス効かないしさ。
インストーラとインストールされる
機
能
Codeer.Friendly Codeer.Friendly.dll Codeer.Friendly.Windows.dll Codeer.Friendly.Windows.Grasp.dll Codeer.Friendly.Dynamic Codeer.Friendly.Dynamic.dll Codeer.Friendly.Windows.NativeStandardControls.dll Codeer.Friendly.Windows.NativeStandardControls.dll Ong.Friendly.FormsStandardControls Ong.Friendly.FormsStandardControls.dll TestAssistantFriendly
の
機
能を使って実装されてた
GUI
操作に
特
化したライブ
ラリ
Codeer.Friendly.Windows.Grasp.dll
Codeer.Friendly.Windows.NativeStandardControls.dll
Ong.Friendly.FormsStandardControls.dll
Window の取得。
ネイティブウィンドウラッパー
Friendly
の
機
能を使って実装されてた
GUI
操作に
特
化したライブ
ラリ
Codeer.Friendly.Windows.Grasp.dll
WindowControl → Window の取得と汎用操作。
Codeer.Friendly.Windows.NativeStandardControls.dll
NativeXXX (NativeButton, NativeEdit, etc)
Ong.Friendly.FormsStandardControls.dll
実
際
に使ってみよう！
オマ
ケ
！
テスト作成
補助
ツール
・画面解析
・クラス解析
・変数動的参照
・メッセージ参照
実
際
に使ってみよう！
そのためには、アプリ操作に
特
化した設計が
必要
！
アプリの操作方法はできるようになったものの・・・。
・テストシナリオも可読性を保つ必要がある。
・プロダクトプロセスの変更に追従する必要がある。
・プログラムなのでメンテが
必要
可
読
性、メンテ
ナ
ンス性を上
げ
る
必要
がある！
でなけれ
ば
、
費
用対
効果
が悪くて、作った
意
味がない！
アプリ
ケ
ーションドライ
バ
← 参照元。
アプリ
ケ
ーションドライ
バ
プロダクトプロ
セス テストシナリオ
ア
プ
リ
ケ
ー
シ
ョ
ン
ド
ラ
イ
バ
アプリケーションドライバはプロダクトプロセスを
アプリ
ケ
ーションドライ
バ
先ほど作ったコードの中には、
内部仕様に基づく情報がテストシナリオの中に存在する。
これは、メンテ性が非常に悪い。
例えば、この画面を使うテストシナリオが複数あると、 コントロール取得コードが散らばってしまう。
そもそも、内部仕様なので、開発者でなければわからない。
それに、開発側が勝手に変えてしまう場合がある。
アプリ
ケ
ーションドライ
バ
・
内
部仕様に
関
する
情報
の
隠蔽
。
・外部仕様を元に
理解
でき、
簡
単に使えるインターフェイスの
提
供
。
外部仕様を元に
理解
できるインターフェイスってなに？
アプリ
ケ
ーションドライ
バ
・
GUI
マップ
・ドメインの
言葉
にしたメソッド、プロパティー
アプリ
ケ
ーションドライ
バ
GUI
マップ
public class MainFormDriver {
public WindowControl MainForm { get; private set; } public FormsTextBox TextBoxName { get; private set; } public FormsTextBox TextBoxAge { get; private set; } public FormsTextBox TextBoxPosition { get; private set; } public FormsButton ButtonAdd { get; private set; }
public FormsButton ButtonFind { get; private set; }
public MainFormDriver(WindowControl form) {
dynamic = form.App.Dynamic();
TextBoxName = new FormsTextBox(form.App, MainForm.textBoxName);
TextBoxAge = new FormsTextBox(form.App, MainForm.textBoxAge);
TextBoxPosition = new FormsTextBox(form.App, MainForm.textBoxPosition);
ButtonAdd = new FormsButton(form.App, MainForm.buttonAdd); ButtonFind = new FormsButton(form.App, MainForm.buttonFind); }
}
GUI を外部仕様としてとらえる。
GUI を特定する変数名称は内部仕様なので、ここで隠蔽する。
これを公開
アプリ
ケ
ーションドライ
バ
ドメインの
言葉
にしたメソッド、プロパティー
public class MainFormDriver {
WindowControl MainForm { get; set; } FormsTextBox TextBoxName { get; set; } FormsTextBox TextBoxAge { get; set; } FormsTextBox TextBoxPosition { get; set; } FormsButton ButtonAdd { get; set; } FormsButton ButtonFind { get; set; }
public MainFormDriver(WindowControl form) {
dynamic = form.App.Dynamic();
TextBoxName = new FormsTextBox(form.App, MainForm.textBoxName);
TextBoxAge = new FormsTextBox(form.App, MainForm.textBoxAge);
TextBoxPosition = new FormsTextBox(form.App, MainForm.textBoxPosition);
ButtonAdd = new FormsButton(form.App, MainForm.buttonAdd); ButtonFind = new FormsButton(form.App, MainForm.buttonFind); }
public void Entry(string name, string age, string position)
{ TextBoxName.EmulateChangeText(name); TextBoxAge.EmulateChangeText(age); TextBoxPosition.EmulateChangeText(position); ButtonAdd.EmulateClick(); } }
隠蔽
公開
GUI操作ではなく、
登録というフィーチャをテストしたい。
メリット
・シナリオはさらにシンプルに。
・GUIが変わっても、メンテはここだけ
。
デメリット
アプリ
ケ
ーションドライ
バ
ショート
カ
ット
目的の状態（画面）まで移動する。
目的の画面の操作は詳細に書きたいとして、
そこにたどり着くまでの画面の操作は、その関心の対象外。 そのため、できたら関数一発で、そこにたどり着きたい。
public static MainFormDriver MoveFromInitialState(WindowsAppFriend app) {
//...遷移コード
}
注）継続的デリバーには、このようなアドバイスはありません。
テストシナリオ
ア
プ
リ
ケ
ー
シ
ョ
ン
ド
ラ
イ
バ
アプリを簡単に操作する
手段を提供するよ。
私の仕事はアプリ操作。
内部仕様も知ってるよ。
でも、それは秘密だけどね。
ていうか、アプリのことは気にしないで
。
私のことをアプリだと思って話して。
外部仕様に沿って、
テストシナリオを簡潔に記述するよ。
私の仕事は品質保証。
難しい内部仕様なんて知りたくもないし。
あれ？
ア
プ
リ
ケ
ー
シ
ョ
ン
ド
ラ
イ
バ
てことは、アプリケーションドライバって 開発者が作ればいいんじゃない？
内部仕様知ってるし。
アプリケーションドライバが使っている内部仕様は
規約として守りやすいしね。
テストシナリオ
てことは、テストシナリオは
検証チームが書いたらいいじゃないかな？ 外部仕様だけで、使えるインターフェイスを
提供してくれるんでしょ？
そういう仕事分担もありです。
まあ、しかし検証チームの本業は検証だし、トラブルが発生したら 開発側がサポートしたり、プログラムの分からないところを教えた り、
それは当然必要。
チームとして自動化を成功させるという認識が重要。
