iOSテスト/仕様TDD / BDDおよび統合と受け入れテスト
IPhoneでの行動駆動型開発に使用するのに最適なテクノロジーは何ですか？そして、これらの技術の適切な使用を実証するいくつかのオープンソースのプロジェクト例は何ですか？ここに私が見つけたいくつかのオプションがあります：
単体テスト
テスト::ユニット スタイル
- OCUnit/SenTestingKit で説明されているとおり iOS開発ガイド：単体テストアプリケーション ＆その他 OCUnit参照 。
- 例： iPhoneUnitTests 、 Three2
- CATCH
- GHUnit
- Mac用Googleツールボックス：iPhone単体テスト
RSpec スタイル
- Kiwi （モックと期待もあります）
- シダー
- Jasmine with I Automation with dexterous 'iOS-Acceptance-Testing specs
受け入れテスト
セレン スタイル
UIオートメーション（デバイス上で動作）
- Iオートメーション機器ガイド
- Iオートメーションリファレンスドキュメント
- Tuneup js -UIAutomationで使用するためのクールなライブラリ。
自動化スクリプトへのユーザーインターフェイスアクションのキャプチャ
Cucumber（JavaScriptで記述） を使用してUIオートメーションを駆動することができます。これは素晴らしいオープンソースプロジェクトです。次に、 Gherkin と書くと、UIオートメーションテストを実行できます。とりあえず、ガーキンをコメントとして書きます。
更新： Zucchini Framework はCucumberとUI Automationをブレンドしているようです！ :)
古いブログ投稿：
ISpec with ISpecRunner
キュウリ スタイル
フランク および iCuke （ Cucumber meets iPhone talk に基づいて）
- Frank Google Group は iCuke Google Group よりもはるかに多くのアクティビティを持っています。
- フランクはデバイスとシミュレータの両方で実行されますが、iCukeはシミュレータでのみ実行されます。
- フランクは、 iCukeのステップ定義 よりも包括的なステップ定義のセットを持っているようです。そして、 フランクのウィキにもステップ定義の概要があります 。
- 私はiCukeとFrankをマージすることを提案しました （MerbとRails_のマージ方法に似ています）は、同じ共通の目標であるCucumber for iOSを持っているためです。
Zucchini Framework は、テストの作成にCucumber構文を使用し、ステップ定義にCoffeeScriptを使用します。
追加
- OCMock for mocking
- OCHamcrest および/または Expecta 予想
結論
まあ、明らかに、この質問に対する正しい答えはありませんが、現在私が選んだものは次のとおりです。
単体テストでは、XCode 4では OCUnit/SenTestingKit を使用していました。これはシンプルで堅牢です。しかし、私たちの言葉は私たちの世界を作り出すので、私はTDDよりもBDDの言語を好みます（ なぜRSpecがTest :: Unitよりも優れているのか ？）。そこで、今では ARCを使用したKiwi ＆ Kiwi code completion/autocompletion を使用しています。 OCUnitの上に構築され、RSpecスタイルのマッチャーとモック/スタブが付属しているため、私はCedarよりもKiwiの方が好きです。更新：現在、 Kiwiはフリーダイヤルブリッジオブジェクトのスタブ化をサポートしていません なので、OCMockを検討しています。
受け入れテストでは、UIオートメーションを使用します。各テストケースを記録できるため、テストを自動的に作成できます。また、Appleが開発しているため、将来性があります。また、デバイス上およびInstrumentsからも機能し、メモリリークの表示など、他のクールな機能を使用できます。残念ながら、UIオートメーションでは、Objective-Cコードを実行する方法がわかりませんが、Frank＆iCukeを使用するとできます。したがって、ユニットテストで下位レベルのObjective-Cをテストするか、 UIButtonビルド構成 のみに対してTESTsを作成し、クリックすると実行されますObjective-Cコード。
どのソリューションを使用しますか？
関連する質問
tl; dr
PivotalでCedarを作成したのは、RubyプロジェクトでRspecを使用しており、大好きだからです。 Cedarは、OCUnitに取って代わるものではありません。 RspecがRubyでBDDスタイルのテストを開拓したように、BDDスタイルのテストの可能性をObjective Cにもたらすことを意図していますが、Test :: Unitを排除していません。どちらを選択するかは、主にスタイルの好みの問題です。
場合によっては、OCUnitが機能する方法のいくつかの欠点を克服するようにCedarを設計しました。具体的には、デバッガをテストで使用し、コマンドラインおよびCIビルドでテストを実行し、テスト結果の有用なテキスト出力を取得できるようにしたいと考えました。これらは多かれ少なかれあなたにとって役に立つかもしれません。
長い答え
（たとえば）CedarやOCUnitなどの2つのテストフレームワークを決定することは、好ましいスタイルと使いやすさという2つのことです。スタイルから始めましょう。それは単に意見と好みの問題だからです。使いやすさはトレードオフのセットになる傾向があります。
スタイルの考慮事項は、使用するテクノロジーや言語を超えています。 xUnitスタイルのユニットテストは、BDDスタイルのテストよりもはるかに長い間使用されてきましたが、主にRspecにより、後者の人気が急速に高まっています。
XUnitスタイルのテストの主な利点は、そのシンプルさと幅広い採用です（ユニットテストを作成する開発者の間で）。コードの作成を検討できるほぼすべての言語には、xUnitスタイルのフレームワークが用意されています。
BDDスタイルのフレームワークは、xUnitスタイルと比較すると、主に2つの違いがあります。テスト（または仕様）の構造と、アサーションを記述するための構文です。私にとって、構造的な違いが主な差別化要因です。 xUnitテストは1次元であり、特定のテストクラスのすべてのテストに対して1つのsetUpメソッドがあります。ただし、テストするクラスは1次元ではありません。多くの場合、競合する可能性のあるいくつかの異なるコンテキストでアクションをテストする必要があります。たとえば、addItem：メソッドを使用した簡単なShoppingCartクラスを考えます（この回答の目的のために、Objective C構文を使用します）。このメソッドの動作は、カートに他のアイテムが含まれている場合と比較して、カートが空の場合に異なります。ユーザーが割引コードを入力した場合は異なる場合があります。指定したアイテムを選択した配送方法で配送できない場合は異なる場合があります。など。これらの可能性のある条件が互いに交差するため、幾何学的に増加する可能性のあるコンテキストになります。 xUnitスタイルのテストでは、これは多くの場合、testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodAppliesなどの名前を持つ多くのメソッドにつながります。 BDDスタイルのフレームワークの構造により、これらの条件を個別に整理することができます。これにより、すべてのケースをカバーしやすくなり、個々の条件を簡単に検索、変更、または追加できます。例として、Cedar構文を使用すると、上記の方法は次のようになります。
describe(@"ShoppingCart", ^{
describe(@"addItem:", ^{
describe(@"when the cart is empty", ^{
describe(@"with no discount code", ^{
describe(@"when the shipping method applies to the item", ^{
it(@"should add the item to the cart", ^{
...
});
it(@"should add the full price of the item to the overall price", ^{
...
});
});
describe(@"when the shipping method does not apply to the item", ^{
...
});
});
describe(@"with a discount code", ^{
...
});
});
describe(@"when the cart contains other items, ^{
...
});
});
});
場合によっては、同じアサーションのセットを含むコンテキストを見つけることができます。これは、共有されたサンプルコンテキストを使用してDRY upできます。
BDDスタイルのフレームワークとxUnitスタイルのフレームワークの2番目の主な違いであるアサーション（または「マッチャー」）構文は、単に仕様のスタイルをいくぶん優れたものにします。本当に好きな人もいれば嫌いな人もいます。
それは使いやすさの問題につながります。この場合、各フレームワークには長所と短所があります。
OCUnitはCedarよりもずっと長く、Xcodeに直接統合されています。これは、新しいテストターゲットを作成するのが簡単であり、ほとんどの場合、テストを実行して「正常に動作する」ことを意味します。一方、iOSデバイスで実行する場合など、OCUnitテストを機能させることはほとんど不可能であることがわかりました。 Cedarの仕様を設定するには、OCUnitテストよりも多くの作業が必要になります。ライブラリを取得し、それに対して自分でリンクしているからです（Xcodeで簡単な作業を行うことはありません）。私たちはセットアップを簡単にするために取り組んでおり、どんな提案でも歓迎です。
OCUnitは、ビルドの一部としてテストを実行します。つまり、テストを実行するために実行可能ファイルを実行する必要はありません。テストが失敗すると、ビルドは失敗します。これにより、テストを実行するプロセスが1ステップ簡単になり、テスト出力がビルド出力ウィンドウに直接表示されるため、見やすくなります。 Cedarの仕様を実行可能ファイルに組み込むことを選択しました。実行可能ファイルは、いくつかの理由で個別に実行します。
- デバッガを使用できるようにしたかったのです。他の実行可能ファイルを実行するのと同じようにCedar仕様を実行するため、デバッガーを同じ方法で使用できます。
- テストで簡単にコンソールにログを記録したかったのです。 OCUnitテストでNSLog（）を使用できますが、出力はビルドウィンドウに送られ、そこでビルドステップを展開する必要があります。
- コマンドラインとXcodeの両方で、テストレポートを読みやすくしたかったのです。 OCUnitの結果はXcodeのビルドウィンドウにきれいに表示されますが、コマンドラインから（またはCIプロセスの一部として）ビルドすると、テスト出力が多くのビルド出力と混ざります。個別のビルドフェーズと実行フェーズにより、Cedarは出力を分離するため、テスト出力を簡単に見つけることができます。デフォルトのCedarテストランナーは、標準スタイルの印刷 "。"をコピーします合格する仕様ごとに、失敗した仕様などに「F」を使用します。Cedarにはカスタムレポーターオブジェクトを使用する機能もあるため、少しの労力で結果を好きなように出力できます。
OCUnitはObjective Cの公式ユニットテストフレームワークであり、Appleによってサポートされています。 Appleには基本的に無制限のリソースがあるため、何かをしたい場合は完了します。そして、結局のところ、これは私たちがプレイしているAppleのサンドボックスです。しかし、そのコインの裏側は、Appleが毎日何千ものサポートリクエストとバグレポートを受け取っているということです。それらはすべてを処理するのに非常に優れていますが、報告した問題をすぐに、またはまったく処理できない場合があります。 CedarはOCUnitよりもはるかに新しく、簡単なものではありませんが、質問、問題、または提案がある場合は、Cedarメーリングリスト（[email protected]）にメッセージを送信してください。また、Github（github.com/pivotal/cedar）からコードをフォークして、不足していると思われるものを自由に追加してください。テストフレームワークをオープンソースにするのには、理由があります。
IOSデバイスでOCUnitテストを実行するのは難しい場合があります。正直なところ、私はかなり長い間これを試していませんでしたので、簡単になったかもしれませんが、前回試したときは、UIKit機能が動作するOCUnitテストを取得できませんでした。 Cedarを書いたとき、シミュレータとデバイスの両方でUIKit依存コードをテストできることを確認しました。
最後に、ユニットテスト用にCedarを作成しました。つまり、UISpecのようなプロジェクトと実際には比較できないということです。 UISpecを使用してからかなりの時間が経ちましたが、主にiOSデバイスでUIをプログラムで駆動することに焦点を当てていることがわかりました。 Appleは（当時）UIAutomationを発表しようとしていたので、Cedarがこれらのタイプの仕様をサポートしないようにすることを特に決定しました。
私は Frank を受け入れテストミックスに投げ込む必要があります。これはかなり新しい追加ですが、これまでのところ私にとってはうまく機能しています。また、icukeなどとは異なり、実際に積極的に取り組んでいます。
テスト駆動開発では、 GHUnit を使用するのが好きです。セットアップが簡単で、デバッグにも最適です。
素晴らしいリスト！
IOSアプリケーションをUIテストするための別の興味深いソリューションを見つけました。
UIAutomationに基づいています。フレームワークを使用すると、画面中心のシナリオをCucumberのようなスタイルで作成できます。シナリオは、シミュレータおよびコンソールからデバイスで実行できます（CIフレンドリーです）。
アサーションはスクリーンショットベースです。柔軟性に欠けますが、画面比較が強調表示されたニースHTMLレポートが得られ、ピクセルを正確に表明する領域を定義するマスクを提供できます。
各画面はCoffeScriptで記述する必要があり、ツール自体はRubyで記述されています。それは一種のポリグロットの悪夢ですが、このツールはUIAutomationに対してニースの抽象化を提供し、画面が記述されるとQAの人でも管理可能です。
受け入れテストにはiCukeを、単体テストにはCedarを選択します。 UIAutomationはAppleにとって正しい方向への一歩ですが、ツールには継続的な統合のためのより良いサポートが必要です。たとえば、現在、InstrumentsでUIAutomationテストを自動的に実行することはできません。
GHUnitは単体テストに適しています。統合テストでは、UISpecを使用して成功しました（github fork here： https://github.com/drync/UISpec ）が、iCukeを試すことを楽しみにしています。軽量なセットアップ。RSpecやCucumberなどのRailsテストの良さを使用できます。
私はOCDSpec2が本当に好きですが、偏見があり、OCDSpecを書いて2番目に貢献しています。
IOSでも非常に高速です。これは、OCUnitの上に置かれるのではなく、一から構築されるためです。 RSpec/Jasmine構文もあります。