Xcode 標準の XCTest Framework を使ったテストについて整理。 導入 プロジェクト作成時に導入する場合は、このようにテストターゲットを含めるようにします。 既存のプロジェクトに導入する場合は、このようにターゲットを追加します。 プロジェクトにはこのようにテストターゲットとテストコードが追加されます。 テスト実行 全てのテストを実行する場合は、 Product -> Test もしくは ⌘ + U で実行します。 メソッド単位やクラス単位でテストを実行する場合は、このように Test Navigator やエディターでテスト対象にマウスカーソルを合わせるとテスト実行ボタンが表示されますので、これをクリックすることでテストを実行します。 テスト結果 テスト結果は、このように失敗すると赤色のアイコンが表示され、成功すると緑色のアイコンが表示されます。 テストコード テストメソ
#はじめに 最近になってOCMockを使ってみたのでメモ。 思ったよりも日本語でまとまった情報がなくて、最初に学習コストがかかったので自分なりにまとめてみる。 詳しい情報については公式ページのリファレンスに記載されているのでそちらを参照のこと。 http://ocmock.org/reference/ （少しずつ書き足していく・・・かも） #概要 Objective-C向けのMockライブラリ。 http://ocmock.org/ XCTestなどでユニットテストを書く際に、依存したオブジェクトをMock化して依存関係を断ち切ってテストできる。（ユニットテストやMockについては本題とずれるので割愛） ##制限事項 Swiftで書かれたコードに対しても利用することはできるが、テストコード自体はObjective-C（XCTestなど）で書く必要がある。 Tests have to be
プロジェクトをつくって簡単なテストが通るのを確認するまで。 ##必要なもの Quick Nimble をcloneしておく。 ##テストコードを書く準備 ###プロジェクトをつくる なんでもいいけど今回はSingleViewでやる。 ###テストターゲットにQuick.xcodeprojとNimble.xcodeprojを追加する プロジェクトの中にある○○Testsを右クリックしてAdd Files to ○○を選択。 cloneしておいたQuick.xcodeprojを選択。 というのをNimble.xcodeprojでもやる。 こんな感じ。 ###Quick.frameworkとNimble.frameworkをリンクする プロジェクトを選択してTARGETSの○○Testsを選択してBuild Phasesタブを表示。 Link Binary With Librariesを開いて+
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? iOS向けライブラリ/アプリの単体テスト手法について調査した内容のメモ。（Objective-C前提です、、） Mantle 1.5 URL https://github.com/Mantle/Mantle/tree/1.5 構成 すべてSpectaを利用した記述 Specta開発元なのでSpecta利用の参考になる 環境定義用クラスはなし pchファイルで補助ツールのインポート テスト実行 TravisCI利用 CI用のスクリプトを定義 補助ツール Expecta Specta Octokit 0.5 URL https://gith
以前作ってGithubに公開していた CrashMonkey というツールについて紹介します。 Github:CrashMonkey CrashMonkey概要 iOSのアプリケーションをモンキーテスト（ランダムな操作をひたすら行う）するためのツールです。 動作イメージはこのデモ動画を御覧ください。 iPhone Simulatorの操作にはUIAutomationを使っていて、ベースとしてui-auto-monkeyを使わせて頂きました。 動作環境 以下の環境でのみ確認してあります。 Max OS X 10.8.4, 10.9.4 Xcode 4.6.3(Build version 4H1503), Xcode5.1.1 Ruby 1.8.7-p371 Rubyについては、1.9系, 2.0系でも動くと思います。 特徴 良い点 アプリのプロジェクト自体に変更を加えなくても実行することがで
Xcode標準のテストライブラリがうまいことやってくれないせいで、非同期処理のテストを書く場合に待ちの処理を自分で書いてあげないといけません。 最近のすごくいい感じの拡張が紹介されたのでこれを使うとなかなかいい感じです。 Objective-Cで非同期処理のテストをシンプルに書く方法 - TOKOROM BLOG ですが、実際はそこまでやらなくてもSDK標準の機能だけでも簡単に実装できます。サンプルコードは以下の通り。 - (void)testExample { CFRunLoopRef rl = CFRunLoopGetCurrent(); NSURLRequest *req = [NSURLRequest requestWithURL:[NSURL URLWithString:@"http://xoyip.hatenablog.com/"]]; NSOperationQueue *qu
非同期処理のテストってどう書いてますか？ 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する（意外とこれが多いかも？） expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
最近TDDやってて意識高まりまくってるので，TDDについてCocoa勉強会関西#54でTDDについて発表してきました． 個人の感想レベルの発表なのでTDDモヒカンの方は斧をおさめてください． スライドはこちらです． スターお待ちしています． あと，サンプルに出した駅探索APIクライアントとテストコードですが，こちらに置いておきました． yashigani/HREClient · GitHub このAPIを叩くやつです．駅検索APIにしか対応してないから使えるかわからんけど一応podspecもつけておきました． XCTest/Kiwi/Spectaのテストがついてますので参考にどうぞ． KiwiとSpectaは同時にビルドできないので，試したいほうをpodfileで有効にして，いらないほうのテストはビルドから外してください． TDDをはじめた感想 参考までにTDDをはじめた筆者の様子を共有し
How the Google+ Team Tests Mobile Apps*1 を3行でまとめるブログ。 ユニットテスト iOS SDK標準のOCUnit(SenTestingKit)を使う Google Toolbox for Mac付属のGTMSenTestcaseクラスもいい。 次のSDKからSenTestingKitは外れるらしいんだけど代替のアップル製のテストフレームワークはSenTestingKitのAPIと互換性がある代替APIがあるというので使い方の意識する必要はなさそう。OCUnitはもともと個人開発者が公開してた昔からある秘伝のソースだからたぶん中身をモダーンに書き直したんじゃないかなーと勝手に予想してる。 GTMは正直iOS開発じゃもうそんなに使わんだろと言っていたけど結構メンテされてるし今度見てみます。 https://code.google.com/p/goog
Objective-C勉強会@8月 Objective-C勉強会@東京 ８月 – Objective-C勉強会＠東京 | Doorkeeper に参加/発表してきたのでメモ 「メタプログラミングとCategory」 – @akuraru Metaprogramming メタプログラミング ロジックを生成する高位ロジックのこと マクロ等 クラスやメソッドを生成するロジックの事 Objective-Cには実行時に行うことができる => カテゴリ カテゴリ コンパイル時に既存のクラスにメソッドを追加、上書きできる機能 ヘッダーファイルを読み込んで無くてもコンパイルできてしまう よいところ 手軽 ファイル分けができる Viewの更新だけを、カテゴリに分けたりすることができる テストするとき便利 カテゴリでテスト用にヘッダーを作れる Objective-Cのテストクラスからプライベートメソッド/プロ
クライアントサーバーアプリ開発では、開発・デバッグ中に問題が発生した時に原因がクライアント側にあるのかサーバー側にあるのか両方の視点から特定していかなければいけない場面に遭遇します。OHHTTPStubsを使うと、手軽に(通信部分のコードに手を入れることなく!)HTTP通信のスタブを実現できて大変便利です。 OHHTTPStubsの基本 [OHHTTPStubs stubRequestsPassingTest:^BOOL(NSURLRequest *request) { return (リクエストに対して偽のレスポンスを返すかどうか); } withStubResponse:^OHHTTPStubsResponse*(NSURLRequest *request) { return (返すレスポンスの内容); }]; 基本的にはスタブしたいHTTP通信が行われる前の適当なタイミングでstub
Objective-C勉強会＠東京 – PARTAKE に参加して、iOSのユニットテストについて話をして来ました。 iOS Unit Test スライドは上記に置いてあります。 そこまで、それぞれに詳しく扱ってない感じで、ロジックテストとアプリケーションテストの違いや、 どういうツールがあるのかやデータベースを使った時にテストの仕方等の紹介な感じです。 xctool はiOSのテストをCLIで実行するのにとても便利でよい感じなのでお勧めです。 スライド内にひっそり(note)とCocoaPodsと xctool の相性がまだ良くないことが書かれていますが、 一度ビルドしないと、 xctool からテストを動かすとエラーになる現象があります。 これは、”Find Implicit Dependencies”の挙動が上手く動いていないのが原因みたいで、手動でビルドの設定にCococPodsの
最近 Kiwiで TDD やってます。Objective-C のテストってすごく書きづらいイメージでしたが、Kiwi はかなり使いやすくてお勧めです。 非同期メソッドを呼んで、そのメソッド内で変更された値をチェックするといったことも簡単にできます。 describe(@"SimpleRemoteObject", ^{ context(@"read remote post object using POST", ^{ beforeAll(^{ [SRRemoteConfig defaultConfig].baseurl = @"http://localhost:2000/"; }); it(@"should get object using POST method", ^{ NSDictionary *params = @{@"key":@"value"}; __block NSArray
Swift is the best programming language you should learn and make your dream app easily. Swift programming is a powerful yet easy-to-learn coding language created by Apple. It's frequently used for developing iOS and macOS applications, as well as tvOS and watchOS apps. While you can use other languages to create Apple apps, Swift is the preferred language, and it's recommended because its code is
以下のような感じで、うごいているっぽいのだけど、本当にこんなので、よいのか？ ↓たぶん、だめみたい。 [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1.0]];をよぶと、 [mm updateNewsstandIssues];が２重起動されるようにみえる?? だめに見えたのは、バグだった模様です。 なので、以下で大丈夫かも。 @implementation spikeTests - (void)setUp { [super setUp]; // Set-up code here. _isDone = NO; } - (void)tearDown { // Tear-down code here. [super tearDown]; } - (void)testModelManage
Objective-CでUnit Testフレームワーク GHUnitの導入手順 Jan 25th, 2013 Tweet Objecitve-CのUnit Testのフレームワークの中では、GHUnitが安定性の面でオススメなようです。ということで、GHUnitの導入にトライしたらドハマリしたので、今後のために導入の手順を残しておきます。 Objective-Cのテストフレームワーク Objective-Cのテストフレームワークの比較は、iOS 向けTDD/BDDフレームワークやモックフレームワークの現状 - laiso - iPhoneアプリ開発グループ がよくまとまっています。ここでの結論は、SenTestingKitが公式でサポートされているのでXCode/iOSのバージョンアップして使い続けられる点で、オススメとのことでした。 一方、TECH-GYM(株式会社プラスアール)さんの
iPhone/iOSの開発をしていく上で、Objective-CでPrivate Methodにアクセスしたいなぁと思うことがあると思います。パブリックメソッドには、外部からのインターフェースのみを実装し、ロジック部分はプライベートメソッドに隠蔽するといったケースは多々あると思います。その場合、ユニットテストはプライベートメソッドに対して行う必要があります。 そもそもObjective-Cでのプライベートメソッドは、どう実装するのでしょうか？実はObjective-Cでは、厳密な意味でのプライベートメソッドは存在しないのです。一般的にはカテゴリーという機能を使って、実装ファイル（.mファイル）に宣言して代用します。次のサンプルのような感じです。 #import "ExampleClass.h" @interface ExampleClass(private) - (void) privat
「お前はvim派？それともemacs派？」「Xcode派」 社内で肩身の狭い思いをしているiOS担当のshobyです。Xcodeも慣れると使いやすいですよ。 さて、今回はGHUnitというテストフレームワークを用いて、非同期通信の単体テストを行う方法を紹介します。 GHUnitとは GHUnitとはMac OS X、 iOS用の単体テストフレームワークです。 Xcode標準のテストフレームワークであるSenTestingKitと互換性があり、 標準フレームワークには無い多くの便利な機能を持っています。 SenTestingKitと比べたGHUnitの利点は以下の通りです。 非同期処理のテストが容易 通信等のテストを簡単に記述できる 実機上でのテストが容易 アプリケーションとして端末上で実行される メモリ容量の制限等、ハードウェアに影響を受ける処理のテストを行える テストを部分的に実行可能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
