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