More Related Content
Similar to GUI Test is (not) necessary
Similar to GUI Test is (not) necessary (20)
More from Hiroshi Maekawa
More from 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日土曜日