-
Notifications
You must be signed in to change notification settings - Fork 336
11.1 iOS開発におけるテストとCI
XcodeにはデフォルトでiOSやOSXに関するテストを行うフレームワークが組み込まれている。 またサードパーティ製のテストフレームワークも数多く存在し、テストの重要性はとても高い。
このセクションではiOSにおけるテストの種類とフレームワークの簡単な紹介を行い、iOSアプリケーションのテストを書く際の注意点について解説します
iOS開発に関するテストはXcodeによってもサポートされており、Appleによると大きくロジックテスト(Logic tests)と機能テスト(Application tests)に分かれます。
ロジックテストでは、各ユニット単体がそれ自体で正しく機能することを確認します。 機能テストではアプリケーションにおいて各ユニットが正しく利用されているかを確認します。
MVCパターンに則ってアプリケーションを作成した時に、モデル層についてのテストはロジックテストで行い、ボタンを押した、キーボードに入力した際の挙動や、正しく画面遷移が行われるか、などのテストを機能テストで行います。
iOSにアプリケーションのテストの歴史は浅く、まだ確立したフレームワークはありません。そこでここでは現在利用可能なテストフレームワークについてロジックテストと機能テストに大別して紹介します。
OCUnit (Sen Testing Framework)はXcodeにデフォルトで含まれているロジックテストのフレームワークです。OCMockはOCUnitでモックを行う時のためのサポートライブラリです。新規プロジェクトを作る際に、"include unit tests"にチェックを入れるとテスト環境が出来上がるので、簡単に導入できます。テストの実行もXcodeから⌘+Uで実行することができます。 一方でアサーションの数の少なさや複数のスレッドにまたがったテストなどを実行できません。
GHUnitもOCUnitと同様に単体のロジックテストを行うフレームワークです。シミュレータ上で動作し、viewに関するテストを実行できる(viewのレイアウトなどを比較できる)、非同期処理のテストを実行できる、と言う点でOCUnitよりも高機能です。CocoaPodsより導入可能です。
KiwiはXcode上でBDDスタイルでテストを書くことのできるフレームワークです。モックを行うことも出来、Xcode上で⌘+Uで実行することができます。
UI AutomationはXcodeにデフォルトで含まれている機能テストのフレームワークです。Instrumentsでシミュレータあるいは実機の動作履歴を覚えておき、その通りに実行することができるかをテストします。テストはJavaScriptで記述します。 ドキュメントについてはこちらをご覧ください。 Automating UI Testing
KIFはSquare, Incがオープンソースで公開している機能テストフレームワークです。テストはObjective-Cで記述し、シナリオ、ステップなどの段階で記述します。導入はCocoaPodsより行うことができるようになりました。
Frankは、Ruby On Railsの受け入れテストフレームワーク、Cucumberを利用してテストを行うことの出来る、機能テストのフレームワーク。テストにおいてはアプリケーション内部に埋め込まれたHTTPServerからテストを実行します。
iOSアプリケーションのテストの実行方法には Xcode上で⌘+U, シミュレータ上でのテスト, 実機上でのテスト, コマンド xcodebuild を用いたコマンドラインからの実行 などいくつかの種類があります。 この実行方法によって、いくつかテストについて制限があります。 例えば、シミュレータ上でのテストの場合、xibを読み込むことができますが、カメラや位置情報を用いたテストは難しいです。 またコマンドラインからのビルドの場合は、xibの読み込みが行われないことがあります。他にも端末への依存が大きいKeyChainなどもアクセスが難しいです。
これらの制限を踏まえた上でテストを記述すること必要となります。
バッチ処理を行う単体テストにおいて、テストは一つのスレッド上で行われることが多く、複数のスレッドでの処理や非同期処理はあまり考慮に入れていないケースが多いです。(OCUnitなど)
そのため、非同期処理のテストを書く場合は非同期処理をサポートしているテストフレームワークを用い、明示的に非同期テストを書く必要があります。GHUnitなどでは非同期処理のテストを行うことが出来ます。
通信を行うテストを利用する場合、レスポンスが常に同一のものでないと正しいテストを行うことができません。そのため、サーバーが常に準備されており常に同じレスポンスをする必要があります。しかし、テストのためのレスポンスを返すサーバーを構築するのはコストがかかりますし、どのような時もサーバーを立てておく必要があります。そのような時はレスポンスをモックしてテストを行うことが多いです。
上述のように、iOSアプリケーションのテストにはいくつか制約や注意点がつきまといます。そのためにも、レスポンスを返すメソッドにする、コントローラにロジックを詰め込まずに、モデル層にロジックを詰め込んでテストを多めに書く、メソッドでは単一のことを行う、など、一般的に言われている テストしやすい設計 を心がけることがiOSアプリケーションの開発においても必要です。
はじめに
-
導入
-
1.3 UIViewController1 UIViewController のカスタマイズ(xib, autoresizing)
-
UIKit 1 - container, rotate-
-
UIKit 2- UIView -
-
UIKit 3 - table view -
-
UIKit 4 - image and text -
-
ネットワーク処理
-
ローカルキャッシュと通知
-
Blocks, GCD
-
設計とデザインパターン
-
開発ツール
-
テスト
-
In-App Purchase
-
付録