gui test is (not) necessary

GUI Test is (not) necessary

@Posaune

13年3月9日土曜日

じこしょーかいまえかわひろし

a.k.a ＠Posaune

やってること

京都アジャイル勉強会 #京アジャ

TABOK勉強会

あーだCoder

Visual Studio 勉強会 ← New!!


すきなもの

.NET言語

C#, F#, XAML系テクノロジ

Emacs歴4ヶ月くらい。

ReSharper無しで生きていけない。

TDD

アジャイル

自動化（Jenkinsさん）

UX, HCD（UCD）

Business Model Generation


最近書いた気がするものJUnit実践入門 MSTestパッチ

http://posaune.hatenablog.com/entry/2012/12/13/085507

NaturalSpecを使ってC#のテストコードを書いてみた。















さて、本題。


GUI Testを定義しとくGUIを用いて実行するテスト

所謂テストフェイズでよく行われるのがたぶんこれ

あんまいいイメージ無いのでは？

エクセル・ホーガン氏に結果をひたすら書き込み

スクリーンショットを証拠写真にしたり

ストップウォッチ片手に処理時間測ったり

基本的に手動のイメージ。

自動化派は目の敵にしがち。


GUI test is necessaryエンドツーエンドテストという考え方。

① Red ② Green

③ Refactor


GUI test is necessaryエンドツーエンドテストという考え方。

① Red ② Green

③ Refactor

☆ E2E Test


エンドツーエンドテストフィーチャ（機能）の実装を自動化された受け入れテストから始める

受け入れテストは外部からのみシステムと相互作用する

ライブラリならAPIからのみ

Webならブラウザ画面からのみ

GUIならGUIからのみ

はやめにシステム全体をエンドツーエンドでテストできる環境を整える（ウォーキングスケルトン）

ビッグバン結合はダメ、絶対。


【必読】【ステマ】【FYI】みんなも「実践テスト駆動開発」を読もう！


GUI Testを行う方法

Record & Play

画像認識系

Coded UI Test

UI Automation


Record & Play所謂操作記録系のソフト

Windowsだと定番はUWSCじゃね？

http://www.uwsc.info/index.html

記録したものをスクリプト化してくれる。システムテストでの連続運転なんかには威力を発揮。

基本的なフォーカスは「操作の自動化」でTDDとは根本的に合わない。

要するに、開発中に入れちゃうとメンテが大変です。

ボタンの位置を変えたら落ちるとか正直勘弁




画像認識系画面を画像認識して捜査対象を探すSikuliってのががあったりする。

http://www.sikuli.org/

こっちのPCでは動かないので省略・・・(´・ω・｀)

そこそこお手軽、そこそこ堅牢？




Coded UI TestVisual Studio Premium以上では、UI操作を.NETコードに変換できるらしいよ！

Pro以下は察して。

・・・あ、今日はいっぱいいそうなMVPな方に見せてもらってください。

マジレスすると、やっぱり「出来上がったUIをテストする」感が強い


UI AutomationUIをコードから操作できるライブラリ

.NET 3.5くらいから整備された

コントロールにIDとか振れるのでちょっとやそっといじったくらいでは壊れない頑丈なテストが書ける。

がんばれば大体のコントロールは操作できる。

WPFもWinFormもOK。

サードパーティはサポートしてたりしてなかったり

某IG社はWinFormはサポートしないってさ。へぇ。


がんばれば？// 操作対象のコントロールへの参照を// 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();


やってられるかー！(ノ｀Д´)ノ彡┻━┻


大人しくWhite使おう。UI Automationをラップしたライブラリで、非常に書きやすい

イメージとしては、WinGUI版のSelenium

地味にThoughtworks謹製だったりする。

今は別の所に移管されたっぽい。

コミットログ見ててもかなりアクティブ。

https://github.com/TestStack/White

同じようなコンセプトでNUnitFormがあるけれどNUnitのバージョン上げる以外の更新がない・・・




Whiteデモ①普通のUI操作


Whiteデモ②モーダルウィンドウ。

メッセージボックス。

メッセージボックスは各位ラップしてプルリクエスト投げようぜ。


Whiteデモ③もうちょい複雑なUI

DataGrid


Whiteデモ③もうちょい複雑なUI

DataGrid

動かない(´・ω・｀)


そんなわけで、ガンガンWhiteでGUIテスト書こう！


・・・


GUI Test is not necessary


GUI Test is not necessary

...not so much


GUIテストに頼っちゃダメどんなに頑張って書いても、やっぱりGUIテストは壊れやすい。

全パターン網羅しようと思ったら恐ろしく複雑なコードになる。

どう頑張ったってスローテストに絶対なる。

GUIテストはあくまで「シンプルな受け入れテスト」の実行に留めるべき。


GUIテストに頼らない為にUIはあくまで表層の実装であることを意識しませう

UI取っ払ってもロジックがちゃんと動くように作るのが重要

そのためにもレイヤー化をちゃんとしましょう。

MVCとかMVVMとかPresentationModelとか。

参考：http://ugaya40.net/architecture/20120804wankuma.html の2つの記事を正座して読もう。


http://ugaya40.net/architecture/20120804wankuma.html




各階層とテストのイメージ（MVVM/PMの場合）

Model

View Model/Presentation Model

UIシンプルな受け入れテストを少数。スモークテストに近い。

シナリオテストレベルをそこそこ記述したい所。結合動作自体はここで完結する

内部の各Objectの動作を記述する詳細なテスト。粒度を細かく、数多く。TDDの細かいステップを踏むのもここ。


UIの動作自体がややこしいんだけど・・・

本当にGUIの描画自体がややこしいのか、GUIの描画プロパティを決めるのがややこしいのか

後者ならViewModelなりPresenterなりに処理を委譲できるはず。

UI：時計を描画

VM：時間を保持

UI：時計を描画

VM/P：針の角度を保持


結局何が言いたかったのかというと

Whiteあたり使えば、GUIテストはSeleniumレベルくらいにはWindowsでも何とかなる（Win32、WPF）

かといってそれに頼りきると脆弱なテストを量産してしまうので非常に(ﾟдﾟ)ﾏｽﾞ-

レガシーだと頼りきらざるをえない時もあるけれど。

GUIテストはあくまで最小限に。

そのためにもちゃんとレイヤー化アーキテクチャを考えるべき。

MVC/MVP/MVVMあたりはテストの観点からも注目。


gui test is (not) necessary

Documents