iOSのUIテスト：QAと開発の友情を信じる必要があるが、自分をflatめない理由

最近、iOSでのiFunnyのUIテストの実装を取り上げました。 この道は厄介で、長く、全体論的です。 それでも、私はこの方向への私の最初のステップを賢い人々と共有したいと思っています。 私たちは真実であるふりをしません-彼らは彼ら自身の製品にすべてを試みました。 そのため、猫の下には、iOSでiFunnyが何であるか、およびUIとツールとコードサンプルに関する多くのフィードバックが必要な理由についての少しの情報があります。

iOSのiFunnyとは

iFunnyは、ユーモアとミームに関するアメリカのアプリケーションで人気があり、毎月1,000万人が視聴しています。 ここですべてがどのように始まったかについてもっと読むことができます 。 iOSでのアプリケーション開発は6年前に開始されましたが、革新的な影響はありません。

• Objective-Cのコードの99％を保持しています。
• 私たちは、きちんとしたモジュール分割を持つ古典的なMVCに準拠しています。
• 依存関係のためにCocoapodsを積極的に使用します。
• 独自のwebmコンテンツプレーヤーを使用します。サードパーティのソリューションの速度が低下したり、コンテンツのループが防止されたりします。 完全にUGCであるiFunnyの場合、このトピックは重要です。
• SDWebImageから分岐して、写真だけでなく、ダウンロードしたコンテンツの残りにも使用します。
• APIについては、RestKitを選択します。これは、ほぼ問題のない数年間の作業で、かなり成熟したフレームワークです。

単体テスト

私たちはすべてを他の方法で回避しています：働くということはミームを見るということです:)

ビジネスロジックと回避策の重要な瞬間に使用する単体テスト。 これは非常に簡単なテストです。モデルのメソッドをテストし、新しいコンテンツの受信をチェックします。

- (void)testIsNewFeaturedSetForContentArrayFalse { FNContentFeedDataSource *feedDataSource = [FNContentFeedDataSource new]; NSMutableArray *insertArray = [NSMutableArray arrayWithArray:[self baseContentArray]]; feedDataSource.currentSessionCID = @"0"; BOOL result = [feedDataSource isNewFeaturedSetForContentArray:insertArray]; XCTAssertFalse(result, @"cid check assert"); feedDataSource.currentSessionCID = @"777"; result = [feedDataSource isNewFeaturedSetForContentArray:insertArray]; XCTAssertTrue(result, @"cid check assert"); } 

使用するテストの2番目のクラスは、クラスをオーバーライドするためのルールをチェックするために必要なテストです。 ある時点で、一連の静的メソッドが異なる、分析システム用の同じタイプのクラスを多数記述する必要がありました。

XcodeとObjective-Cは、誤って記述されたコードから保護するためのソリューションを提供しませんでした。
したがって、このテストを作成しました。

 - (void)testAllAnalyticParametersClasses { NSArray *parameterClasses = [FNTestUtils classesForClassesOfType:[FNAnalyticParameter class]]; for (Class parameterClass in parameterClasses) { FNAnalyticParameter *parameter = [parameterClass value:@"TEST_VALUE"]; XCTAssertNotNil(((FNAnalyticParameter *)parameter).key); XCTAssertNotNil(((FNAnalyticParameter *)parameter).dictionary); } } 

ここでは、クラスに2つの静的メソッド、キーとディクショナリが含まれていることを確認します。これらは、イベントを分析システムに正しく送信するために必要です。

UIテスト

UI要素の操作方法についてはすでに十分に研究しており、Android向けのテストを作成する際のテスト環境についても検討しています。 次のような結果になりました。

• 毎回テストで手動で設定しないように、プリセットを使用してアプリケーションを起動するための個別のフレーバー。
• WireMockを使用したAPIのモック。これにより、毎回サーバーの答えにたどり着き、それに依存することがなくなります。
• テストの起動プロセスを試し、CI Bitriseで非常に便利なフローを設定しました。AmazonDevice Farmの実際のデバイスでテストが実行され、実行されます。Bitriseのリンクをクリックすると、スクリーンショットとビデオを含むレポートを確認できます。

新しいバージョンを開発し、すべてが落ち着くのを待っていたため、ストリームに追加できませんでした。 現在、テストベースの復元と開発を積極的に行っています。

iOSの転換期が到来しました。QAチームとiOS開発者は、再び集まって、なぜ自動テストが必要なのかを議論することから始めました。 それは重要な儀式であり、マントラのように振る舞いました。

• 手動チェックを減らします。
• 回帰を自動化します。
• アプリケーションの継続的なテストを提供して、いつでもアプリケーションの状態を把握できるようにします。

ツール

私たちはツールの選択から始めました。 議題には3つの主要なフレームワークがあり、現在ではモバイルアプリケーションのテストに最もよく使用されています。 それぞれを試してみました。


Appiumは人気のあるクロスプラットフォームフレームワークです。 近い将来、モバイルアプリケーションをテストする際の標準になると考えられています。 数ヶ月前、iOS 10が半年リリースされたのでテストすることにしましたが、少し動揺しました：サポート付きのAppiumのバージョンはベータ版であり、製品版では不安定なバージョンを使用したくありませんでした。 Androidで実行されるAppium Inspectorを使用できませんでした。Xcode8とiOS 10のサポートはありませんでした。すぐに安定バージョンをリリースしましたが、軸を更新してから6か月待つことは非常に望ましくありません。 私たちは自分自身やAppiumを苦しめないことにしました。


Calabashはクロスプラットフォームのオープンソースソリューションであり、テストの作成にBDDアプローチを使用し、最近までXamarinでサポートされていました。 最近、開発者はサポートがすべてだと言った。 また、これ以上進まないことにしました。


そして最後に、 XCTestは最終的に選択したAppleのネイティブフレームワークです。 したがって、長所について読んでください：

• プロジェクトにある不必要な依存関係はありません。
• Apple自身を除いて、外部からの誰もバグをもたらしたり追加したりしません。 すでにAppiumとKIFの経験があります。 XCTestがまだ下部で使用されており、AppleのバグがKIFのバグに重ねられていることがわかりました。つまり、座って、仲間で、大きなフレームワークを選ぶということです。 これらの依存関係は絶対に必要ありませんでした。
• 標準のiOS開発言語であるObjective-CおよびSwiftを使用できます。QAは開発者と簡単にやり取りできます。
• テスト対象のアプリケーションはブラックボックスです。また、テストでは、システム内の任意のアプリケーションで作業できます。

次に、AppleのネイティブツールRecorderを検討しました。これは、実際のテストを作成するときに使用されることを期待せずに、補助ツールとして位置付けられています。 これを使用すると、UI要素のラベルを調べて、基本的なジェスチャーをいじることができます。 開発中に行われなかった場合、Recoderはコード自体を記述し、オブジェクトへのポインターを生成します。 これが唯一の利点です。 さらに多くのマイナスがありました：

• UIの速度が低下するため、テストを記録するのは困難です。アクションを実行して、記録されるまで10〜15秒待ちます。 不便。
• コードは常に異なります。 今日、私はとても賢く、この要素ボタンを[1]、明日は「スマイルボタン」と呼んでいます。 わかりにくい;
• ジェスチャ認識の永続的なエラー。 左にスワイプすると、タップであると判断されます。 タップすると、これは既にスワイプされています。 不安定;
• Recorderで記録された壊れたテストは、実際の状況を反映しないため、再度完全に書き換える必要があります。 ただのWTF ?!

開発者は急いで支援する

次に、実際に発生した問題について説明します。開発に関与することでそれらを解決します。

ブラックボックス

ブラックボックスのプラスはマイナスに変わります。デバイスまたはシミュレーター上のアプリケーションの現在の状態を知ることはできません。 それをリセットし、Androidと同様に、どの国で、どのユーザーとやり取りしたいかをアプリケーションに通知する特定の環境を作成する必要があります。 これはすべて、アプリケーションの起動設定を使用して解決されます。

Xcodeの事前アクションも必要でした。 各テストの前に作業環境をリセットするために、インストールされたアプリケーションをシミュレーターから削除して、ユーザー設定とサンドボックスに保存されているすべてのものをリセットすることにしました。

 xcrun simctl uninstall booted ${PRODUCT_BUNDLE_IDENTIFIER} 

環境変数では、次のように動作します。

 app = [[XCUIApplication alloc] init]; app.launchEnvironment = @{ testEnviromentUserToken : @"", testEnviromentDeviceID : @"", testEnviromentCountry : @"" }; app.launchArguments = @[testArgumentNotClearStart]; 

テストでは、アプリケーションオブジェクトが作成され、アプリケーションに転送する必要がある設定を持つディクショナリ（または配列）がlaunchEnviromentおよびlaunchArgumentsフィールドに書き込まれます。 アプリケーションでは、設定と引数はメソッドのアプリケーションの最初のデリゲートで読み込まれます。

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 

したがって、処理を行います。

 NSProcessInfo *processInfo = [NSProcessInfo processInfo]; [FNTestAPIEnviromentHandler handleArguments:processInfo.arguments enviroment:processInfo.environment]; 

TestAPIEnvHandlerクラスは、構成辞書と引数の配列の処理を実装します。

アイテムのプロパティ

UIのestで作業を始めたとき、問題がありました。標準のツールセットではフォントと色の読み取りが許可されていません。

要素のジェスチャのみを使用できますが、要素に記述されたテキストを読み取ったり、その位置やUIテストに興味深いその他のプロパティを取得したりすることはできません。

代替ソリューションを検索した後、UIテストが機能するAccessibility APIに注目しました。

テストとアプリケーション間の「橋」として、accessibilityValueを使用することにしました。これは、iOS SDKのすべての可視要素にあります。

自転車が行き、次の決定が判明しました。

1. accessibilityValueに、json文字列を記述します。
2. テストでは、読み取りとデコードを行います。
3. UI要素の場合、テストで必要なフィールドのセットを定義するカテゴリを作成します。

UIButtonの例を次に示します。

 @implementation UIButton (TestApi) - (NSString *)accessibilityValue { NSMutableDictionary *result = [NSMutableDictionary new]; UIColor *titleColor = [self titleColorForState:UIControlStateNormal]; CGColorRef cgColor = titleColor.CGColor; CIColor *ciColor = [CIColor colorWithCGColor:cgColor]; NSString *colorString = ciColor.stringRepresentation; if (titleColor) { [result setObject:colorString forKey:testKeyTextColor]; } return [FNTestAPIParametersParser encodeDictionary:result]; } @end 

テストでaccessibilityValueを読み取るには、アクセスする必要があります;このため、各XCUElementオブジェクトには値フィールドがあります。

 XCUIElement *button = app.buttons[@"FeedSmile"]; NSData *stringData = [button.value dataUsingEncoding:NSUTF8StringEncoding]; NSError *error; NSDictionary *dictionary = [NSJSONSerialization JSONObjectWithData:stringData options:0 error:&error]; 

ユーザーインタラクション

ジェスチャとアクションの問題は解決されました（見よ！）ツール自体によって、タップ、ダブルタップなどの標準的な方法の大きなセットのおかげです。 しかし、このアプリケーションには、標準だけでなく、非常に重要なものもあります。 たとえば、トリプルタップでは、すべての軸に沿って異なる方向にスワイプします。 これを解決するために、パラメーターを構成するのと同じ標準的な方法を使用しました。 これは大きな破片ではありませんでした。

アプローチを使用した簡単なテストの例：

• 特定の設定でiFunnyを起動します。
• 国を選択してください。
• 目的のユーザーを選択します。
• 追加の設定を指定します（これが最初のアプリケーション起動かどうか）。
• テープのオープンとコンテンツのロードを確認します。
• 笑顔を作ります。
• コンテンツが平滑化されているか（ボタンの状態が変更されたか）UIを確認します。 スクロールし続けます。
• メカニックを見て、人生を楽しみます。

 - (void)testExample { XCUIElement *feedElement = app.otherElements[@"FeedContentItem"]; XCTAssertNotNil(feedElement); XCUIElement *button = app.buttons[@"FeedSmile"]; [button tap]; [[[[XCUIApplication alloc] init].otherElements[@"FeedContentItem"].scrollViews childrenMatchingType:XCUIElementTypeImage].element tap]; NSDictionary *result = [FNTestAPIParametersParser decodeString:button.value]; CIColor *color = [CIColor colorWithString:result[testKeyTextColor]]; XCTAssertFalse(color.red - 1.f < FLT_EPSILON && color.green - 0.76f < FLT_EPSILON && color.blue - 0.29f < FLT_EPSILON, @"Color not valid"); XCUIElement *feed = app.scrollViews[@"FeedContentFeed"]; [feed swipeLeft]; [feed swipeLeft]; [feed swipeLeft]; } 

完全なテストカバレッジを行う予定はなかったため、ここで実験が終了しました。 プロセスで自動テストを完全に実装することを決定した場合、XCtestを使用することが明らかになりましたが、これを継続的に実行することは非常に困難です。 理由は次のとおりです。

• それでも車輪を再発明する必要があります。
• QAは、開発者なしでアプリケーションを完全にテストすることはできません。
• 製品開発のためのUIテスト-これはくだらない機能であり、例外的な場合にのみ適用できます。

PSプレビューを撮影するとき、単一のバグが傷つかなかった。 Semyonは引き続きQAチームを刺激します。