Weitere ähnliche Inhalte
Ähnlich wie GUI Test is (not) necessary (20)
Mehr von Hiroshi Maekawa (20)
GUI Test is (not) necessary
- 2. じこしょーかい
まえかわ ひろし
a.k.a @Posaune
やってること
京都アジャイル勉強会 #京アジャ
TABOK勉強会
あーだCoder
Visual Studio 勉強会 ← New!!
13年3月9日土曜日
- 3. すきなもの
.NET言語
C#, F#, XAML系テクノロジ
Emacs歴4ヶ月くらい。
ReSharper無しで生きていけない。
TDD
アジャイル
自動化(Jenkinsさん)
UX, HCD(UCD)
Business Model Generation
13年3月9日土曜日
- 4. 最近書いた気がするもの
JUnit実践入門 MSTestパッチ
http://posaune.hatenablog.com/entry/
2012/12/13/085507
NaturalSpecを使ってC#のテストコードを書いてみ
た。
http://posaune.hatenablog.com/entry/
2012/12/08/001052
13年3月9日土曜日
- 6. GUI Testを定義しとく
GUIを用いて実行するテスト
所謂テストフェイズでよく行われるのがたぶんこれ
あんまいいイメージ無いのでは?
エクセル・ホーガン氏に結果をひたすら書き込み
スクリーンショットを証拠写真にしたり
ストップウォッチ片手に処理時間測ったり
基本的に手動のイメージ。
自動化派は目の敵にしがち。
13年3月9日土曜日
- 7. GUI test is necessary
エンドツーエンドテストという考え方。
① Red ② Green
③ Refactor
13年3月9日土曜日
- 8. GUI test is necessary
エンドツーエンドテストという考え方。
① Red ② Green
☆ E2E Test
③ Refactor
13年3月9日土曜日
- 9. エンドツーエンドテスト
フィーチャ(機能)の実装を自動化された受け入れ
テストから始める
受け入れテストは外部からのみシステムと相互作用
する
ライブラリならAPIからのみ
Webならブラウザ画面からのみ
GUIならGUIからのみ
はやめにシステム全体をエンドツーエンドでテスト
できる環境を整える(ウォーキングスケルトン)
ビッグバン結合はダメ、絶対。
13年3月9日土曜日
- 11. GUI Testを行う方法
Record & Play
画像認識系
Coded UI Test
UI Automation
13年3月9日土曜日
- 12. Record & Play
所謂操作記録系のソフト
Windowsだと定番はUWSCじゃね?
http://www.uwsc.info/index.html
記録したものをスクリプト化してくれる。システムテ
ストでの連続運転なんかには威力を発揮。
基本的なフォーカスは「操作の自動化」でTDDとは根
本的に合わない。
要するに、開発中に入れちゃうとメンテが大変です。
ボタンの位置を変えたら落ちるとか正直勘弁
13年3月9日土曜日
- 13. 画像認識系
画面を画像認識して捜査対象を探すSikuliってのが
があったりする。
http://www.sikuli.org/
こっちのPCでは動かないので省略・・・
(´・ω・`)
そこそこお手軽、そこそこ堅牢?
13年3月9日土曜日
- 14. Coded UI Test
Visual Studio Premium以上では、UI操作を.NETコ
ードに変換できるらしいよ!
Pro以下は察して。
・・・あ、今日はいっぱいいそうなMVPな方に見せ
てもらってください。
マジレスすると、やっぱり「出来上がったUIをテス
トする」感が強い
13年3月9日土曜日
- 15. UI Automation
UIをコードから操作できるライブラリ
.NET 3.5くらいから整備された
コントロールにIDとか振れるのでちょっとやそっとい
じったくらいでは壊れない頑丈なテストが書ける。
がんばれば大体のコントロールは操作できる。
WPFもWinFormもOK。
サードパーティはサポートしてたりしてなかったり
某IG社はWinFormはサポートしないってさ。
へぇ。
13年3月9日土曜日
- 16. がんばれば?
// 操作対象のコントロールへの参照を
// AutomationElementオブジェクトとして取得
AutomationElement txtInput = FindElement(aeForm, "txtInput");
AutomationElement btnAdd = FindElement(aeForm, "btnAdd");
AutomationElement lstResults = FindElement(aeForm, "lstResults");
// 操作対象のコントロール・パターンを取得
ValuePattern vpTxtInput =
(ValuePattern)txtInput.GetCurrentPattern(ValuePattern.Pattern);
InvokePattern ipBtnAdd =
(InvokePattern)btnAdd.GetCurrentPattern(InvokePattern.Pattern);
// 1つ目の値を入力、[追加]ボタン押下
vpTxtInput.SetValue("ねこ");
ipBtnAdd.Invoke();
// 2つ目の値を入力、[追加]ボタン押下
vpTxtInput.SetValue("いぬ");
ipBtnAdd.Invoke();
13年3月9日土曜日
- 18. 大人しくWhite使おう。
UI Automationをラップしたライブラリで、非常に書
きやすい
イメージとしては、WinGUI版のSelenium
地味にThoughtworks謹製だったりする。
今は別の所に移管されたっぽい。
コミットログ見ててもかなりアクティブ。
https://github.com/TestStack/White
同じようなコンセプトでNUnitFormがあるけれど
NUnitのバージョン上げる以外の更新がない・・・
13年3月9日土曜日
- 20. Whiteデモ②
モーダルウィンドウ。
メッセージボックス。
メッセージボックスは各位ラップしてプルリクエス
ト投げようぜ。
13年3月9日土曜日
- 21. Whiteデモ③
もうちょい複雑なUI
DataGrid
13年3月9日土曜日
- 22. Whiteデモ③
もうちょい複雑なUI
DataGrid
動かない(´・ω・`)
13年3月9日土曜日
- 27. GUI Test is not
necessary
...not so much
13年3月9日土曜日
- 28. GUIテストに頼っちゃダメ
どんなに頑張って書いても、やっぱりGUIテストは
壊れやすい。
全パターン網羅しようと思ったら恐ろしく複雑なコ
ードになる。
どう頑張ったってスローテストに絶対なる。
GUIテストはあくまで「シンプルな受け入れテス
ト」の実行に留めるべき。
13年3月9日土曜日
- 29. GUIテストに頼らない為に
UIはあくまで表層の実装であることを意識しませう
UI取っ払ってもロジックがちゃんと動くように作
るのが重要
そのためにもレイヤー化をちゃんとしましょう。
MVCとかMVVMとかPresentationModelとか。
参考:http://ugaya40.net/architecture/
20120804wankuma.html の2つの記事を正座して読
もう。
13年3月9日土曜日
- 30. 各階層とテストのイメージ
(MVVM/PMの場合)
シンプルな受け入れテスト
UI を少数。スモークテストに
近い。
シナリオテストレベルをそ
View Model/ こそこ記述したい所。結合
Presentation Model 動作自体はここで完結する
内部の各Objectの動作を記
述する詳細なテスト。粒度
Model を細かく、数多く。TDDの
細かいステップを踏むのも
ここ。
13年3月9日土曜日
- 31. UIの動作自体がややこしいんだけど・・・
本当にGUIの描画自体がややこしいのか、GUIの
描画プロパティを決めるのがややこしいのか
後者ならViewModelなりPresenterなりに処理を
委譲できるはず。
UI:時計を描画 UI:時計を描画
VM:時間を保持 VM/P:針の角度を保持
13年3月9日土曜日
- 32. 結局何が言いたかったのかというと
Whiteあたり使えば、GUIテストはSeleniumレベルく
らいにはWindowsでも何とかなる(Win32、WPF)
かといってそれに頼りきると脆弱なテストを量産し
てしまうので非常に(゚д゚)マズ-
レガシーだと頼りきらざるをえない時もあるけれど。
GUIテストはあくまで最小限に。
そのためにもちゃんとレイヤー化アーキテクチャを
考えるべき。
MVC/MVP/MVVMあたりはテストの観点からも注目。
13年3月9日土曜日