- SlideBoom

第１回 Andoird テスト祭り
尾上雅則
Agenda
1. テストの価値向上再考
2. Android/iOS開発で推奨されるUI設計パターン
3. Presentation Modelパターン
4. UI設計パターン実践時の注意点
5. まとめ- Androidコミュニティとテストと設計パターン
6. 自己紹介(え
ユーザーインターフェースのテストは難しい
１．テストの価値向上再考
UIテスト
 UIのテストは、目視による確認が基本。
→ テスト結果の自動確認
ができない
→ 完全な自動リグレッション
テストが構築できない
→１テストの価値を向上させると
いうアプローチはとれる
１．テストの価値向上再考
テストの価値向上のための責務分割
 適切な責務分割は１テストの価値を上げる。
 例えば27個のユースケース
ユースケース1
ユースケース2
27個のユースケース
ユースケース3
27個のテストケース
ユースケース4
ユースケース5
１．テストの価値向上再考
テストの価値向上のための責務分割
 適切な責務分割は１テストの価値を上げる。
 例えば27個のユースケース
Ａ
Ｄ
Ｇ
Ｂ
Ｅ
Ｈ
Ｃ
Ｆ
Ｉ
２７個のユースケースが、
3 × 3 × 3の機能で成り立っていたら・・・
１．テストの価値向上再考
テストの価値向上のための責務分割
全く責務分割されていない27つのユース
ケースのテストと比較すると、コードが減
り、品質・テストの質が向上しやすい
Ａ
Ｄ
Ｇ
Ｂ
Ｅ
Ｈ
Ａ～Iまでの９個のテストで
Ｃ
Ｉ
Ｆ
単体レベルのテストが可能に！
１．テストの価値向上再考
テストの価値向上のための責務分割
また適切に責務分割されていればいるほど、
単一責任の原則が守られているという事な
ので、適切なテストケースを導出しやすく。
Ａ
Ｄ
Ｇ
Ｂ
Ｅ
Ｈ
Ｃ
Ｆ
Ｉ
１．テストの価値向上再考
テストの価値向上のための責務分割
結合してのテストを考えても、単体テスト
の価値が向上しているため、バグを修正す
る際、修正の連鎖やそもそもバグが減少
Ａ
Ｄ
Ｇ
Ｂ
Ｅ
Ｈ
Ｃ
Ｆ
Ｉ
１．テストの価値向上再考
テストの価値向上のための責務分割
責務分割がもたらすのはもちろんテストの
価値向上だけではない。
 変更に強く
 コードの見通しがよく
 再利用性が向上し、
 開発の分担もしやしく
１．テストの価値向上再考
テストの価値向上のための責務分割
ではどう責務分割していくか？
先人たちのベストプラクティスの形として、
各種設計パターンが存在します。
そしてもちろんAndroid開発においても、
推奨されるパターンが存在します。
Android/iOSには共通で推奨されるパターンがあります
２．Andoird/iOSで推奨されるGUI設計パターン
MVC ( MVP )
 Model – View - Controller
 Model – View – Presenter
 使い古され、
 枯れたといわれ、
 亜種だらけでMVCという名前に共通認識がなく、
 しかしGUIアプリを作成する上で決して無視で
きないパターンです。
その目的は、
プレゼンテーションロジックとドメインロジック
の分離
２．Android/iOSで推奨されるGUI設計パターン
MVC ( MVP )
GUIアプリの責務分割を考える上で、
誰もが考えるのが、
アプリケーションの見た目と操作に関わる部分と、
(プレゼンテーションロジック)
アプリを作る動機でもあった解決したい問題領域に関
わるコード
(ドメインロジック)
の分離。そしてそれはMVC系パターンの大目的です。
２．Android/iOSで推奨されるGUI設計パターン
MVC
Controller
View
Model
⑥変更(⑤が変更依頼な時のみ)
２．Android/iOSで推奨されるGUI設計パターン
MVC
Controller
ViewとConrollerが
プレゼンテーションロジック
を担当
View
View: UIの外観制御
Controller:
入力と通知の橋渡し
Model
Model:ドメインロジック
２．Android/iOSで推奨されるGUI設計パターン
MVCがテストにもたらす価値
ModelとControllerはともにコードがINとOUTになり、
自動テスト可能になります。
Viewは
ユーザアクション
View
Controllerから
上記２種類の契機(トリガー)をもって、
自身の状態を変化(アクション)させるだけの
オブジェクトと捉えられる
自動テスト可能な範囲が増えた！
MVC系派生パターンの一つです。
３．Prensentation Modelパターン
Presentation Modelパターンの紹介
 MVC派生パターンのひとつ
View
Presentation
Model
Model
監視
ViewはPresentation Modelを
レンダリングするだけの存在
Viewを変更したい時はPresentation Modelを変
更する事でViewが変更されるという形が理想
３．Prensentation Modelパターン
Presentation Modelパターンの紹介
Presentation
View
ViewとPresentation
Model
Model
Modelの同期実装
監視
コスト高そうって思いますよね？
ViewはPresentation
Modelを
レンダリングするだけの存在
Viewを変更したい時はPresentation Modelを変
更する事でViewが変更されるという形が理想
３．Prensentation Modelパターン
android-binding
 ProjectHome: http://code.google.com/p/android-binding/
 CodeProject: http://www.codeproject.com/KB/android/androidbinding.aspx
 日本語情報 @nakajiさんのブログ
 Android Bindingを使ってみた(1)～(3)
 http://d.hatena.ne.jp/nakaji999/20110616/1308236700
Android-binding はAndroid用
データバインディング機構
３．Prensentation Modelパターン
android-binding
View側
<Button android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text=“Calc"
binding:onClick="Calculate"/>
<TextView android:id="@+id/b"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
binding:text="BMI"/>
３．Prensentation Modelパターン
android-binding
PresentationModel側
public void Calculate() {…};
public void setBMI(double bmi)
{…
//変更通知
notifyPropertyChanged(“BMI”);}
public String getBMI() {return …}
３．Prensentation Modelパターン
android-binding
Android-bindingの使用により、
Viewは
POJOなPrensentationModelのレンダリング
とすることができる。
PresentationModelの状態がViewの状態を決定
３．Prensentation Modelパターン
android-bindingを使用したPMパターン
Viewからの入力を伝える
(バインディングは単方向なので)
Controller
(Activity)
Presentation
Model
View
バインディング
Model
監視
３．Prensentation Modelパターン
android-bindingを使用したPMパターン
PresentationModelはUIの状態ストアだ
から、画面内で動的に変化するすべての情
報を含みます。
Viewからの入力を伝える
(バインディングは単方向なので)
• チェックボックスがチェックされている
Controller
か否か
(Activity)
• クリックされたときのボタンの背景色
• 表示されているリストの各項目
Presentation
View
Model
バインディング
Model
監視
など。
３．Prensentation Modelパターン
PMパターンがテストにもたらす価値
MVCより、Viewの一部がさらに自動テスト可能な状
態に置き換わっている。
MVCで言うViewからViewが保持している状態が分
離された！
POJOなので、実機・エミュレータなどがなくても自
動テスト可能に。
また、表示の反映ロジックがバインディング機構の
中に隠蔽されたため、ユーザーコードが減り、テス
トで個々に検証するべきコードも減った。
３．Prensentation Modelパターン
Presentation Modelパターン補足
PMパターンはandroid-bindingのような機構が存
在して初めて成立するパターン。ないと冗長過。
つまり、プラットフォームや使用ライブラリの機能によって
大きく形が異なり、ViewとPresentationModel間の責務も揺
らいだりする。
WPF/Silverlight(Windows Phone7含)では、PMパターンは
MVVM(Model – View - ViewModel)パターン
と呼ばれます。
MVVMではViewModel(PM)にボタンの色まで持ったりしない。
(Viewを記述するDSL性能・バインディングが双方向)
UIパターンで実践時にはまりやすいところのご紹介
MVCかPMか、とかに依りません
４．UIパターン実践時のはまり所
Webから来た人が３層にだまされる
 Web開発経験者の中には３層というだけで、こんな
形にしちゃう人がいます。
 AndoridじゃMVCもPMも一見３層なので注意が必要。
画面
ビジネス
ロジック
データ
アクセス
プレゼンとドメインの分離ができていません。
真ん中は実際は画面制御もすることになりますね。
MVC系のそもそもの目的はどこに？
ビジネスロジックもデータアクセスもModelの中が適切
４．UIパターン実践時のはまり所
サーバと通信するアプリのModelは・・？
クライアント側はPresentationModelからという考え
View
Presentation
Model
Model
(サーバ)
通信ロジックとか、ユーザーIDとか管理するのは
PresentationModelなの？プレゼンとドメインが(ry
サーバとクライアントは違う目的を持つ違うアプリです。
Modelはほぼ必ずクライアント側にもある層ですよ。
４．UIパターン実践時のはまり所
(前提)ステートレス？ステートフル？
リッチクライアントはステートフル(状態を持つ)もの
でしょ？。Webみたいにリクエスト毎がオブジェクト
のライブサイクルじゃないです。
View
Presentation
Model
Model
この前提をしっかり認識していないと
次のページで紹介する罠が理解できず。。。
４．UIパターン実践時のはまり所
Modelはただのデータの入れ物？
ステートフルなModelがただのデータの入れ物という
考え。やはりWebからの人が(ry
View
Presentation
Model
Model
入れ物にデータを入れるのはどこの層なのよ？PM？
やはりビジネスとプレゼンの分離が(ry
リッチクライアントのModelは操作を持ちますし、自身の状態
を変化させたり、別のオブジェクトに変化を通知しますよ。
まとめ
５．AndoridコミュニティとテストとUI設計パターン
UI設計パターンがもたらす価値
MVC/PMなど問わず、
 設計パターンは、先人たちのベストプラクティス集
 ベストプラクティス = 責務分割のベストプラクティ
ス
 UI設計パターンの導入は適切な責務分割を推進する。
 適切な責務分割は、一般的なメリットの他に、テス
トの価値を高める。
５．AndoridコミュニティとテストとUI設計パターン
UI設計パターンの利用
 パターンは育つ！
 ベストプラクティスは成長する
 たとえばandroid – bindingで双方向バイ
ンディングが実現したら？
 さらにユーザーコードが減り、テストの
価値も上がる。
５．AndoridコミュニティとテストとUI設計パターン
コミュニティとパターン
 ベストプラクティスの共有
 コミュニティ
 ちょっと触って使えないとか言わない
 フィードバックして成長させる。
 代替パターンを提案してもよい
 次回はもっと効率的な開発ができる。
 コミュニティが開発者を幸せにする。
なぜか最後に自己紹介
 ちょっと反応が怖くて最後にさせていただきました。
 尾上雅則(おのうえまさのり)
 27歳
 .NET(C#/VB.NET)専門のフリーランス7年目。
 ここ２年間、WPF/Silverlight用のPMパターン、
MVVMパターンを中心に追い、コミュニティ活動も
MVVM絡みがほとんど。
 Blog : the sea of fertility – http://ugaya40.net
 Twitter：@ugaya40

Download Report