iOSプロジェクトでのUIテスト。 利益はありますか、なぜ一般的に導入されるのですか

開発のこの部分は顧客に販売するのが非常に難しく、なぜ彼らが必要なのか、なぜそんなに時間がかかるのかを主張するので、UIテストを少なくとも一度だけ書くのではなく、商業プロジェクトでそれを行う人はかなりいます。 ノボシビルスクのImprove Digitalは、特に開発中のプロジェクトが長期的であり、さらなる開発の大きな可能性があるという事実により、いくつかの理由でこのステップを踏むことを決定しました。



次に、 AppsConf 2017でのMikhail Domrachevのスピーチのデコードで、実際にiOSプロジェクトにUIテストを組み込む方法について話し、本当に必要なときと不要なときの考えを共有しました。



将来を見据えて、長所と短所があることに注意してください。 しかし、私たちの意見では、手動テストの莫大な人件費なしで設計バグの数を大幅に削減することは、誰もがわずかな困難を伴うことで試してみるべき否定できない利点です。

背景

設計の問題に直面する前に、プロジェクトの説明から遠くから始めましょう。

• このプロジェクトは2年間活発に発展し続けており、長期的と言えます。
• 開発チームは成長しています。
• このプロジェクトは、共通の機能を備えた多くのモバイルアプリケーションで構成されています。
• コアフレームワークが開発されました。このフレームワークでは、一般的な機能が強調表示され、ビデオサブモジュールの各プロジェクトに接続されています。

私たちは、さまざまな国に支店を持つかなり大きな外資系金融会社と協力しています。 各国には独自のモバイルアプリケーションがあり、共通の機能を備えていますが、国のデザインや特定の点で異なり、たとえば法律に関連付けられています。

技術面

すべての画面は表形式で実装されています。 テーブルは、セルやそのビューモデルなどのバンドルのセットで構成されます。 つまり、View-Modelを使用してセルのコンテンツをカスタマイズし、特定のデザインを設定することができます。国によって外観は異なりますが、実際にはCoreフレームワークにあるのは同じリソースです。







図は画面を示しています。 上部のセルには独自のビューモデルがあり、これを介して次のことができます。

• 背景色をカスタマイズし、
  
  
• リソースから取得した画像の名前（imageName）を設定します。
  
  

ボタンの表示モデルでは、次を設定できます。

• コンテンツ（タイトル）、
  
  
• デザイン（タイトルの色）、
  
  
• このボタンの背景色。
  
  

コアフレームワーク

平均して、新しいアプリケーションごとに、Coreフレームワークの機能の約70％を再利用し、30％だけが新しいものを取得します。







コアフレームワークには次の場所があります。

• 画面モジュール -モジュール形式の既製画面。 私はそれらをモジュールと呼んでいます。なぜなら、彼らはすでにいくつかの標準的なビジネスロジックを実装し、他の画面への移行をルーティングし、デフォルトのデザインがあるからです。
  
  
• 任意のサービス -たとえば、ネットワーク、データキャッシュなどの操作のためのさまざまな基本サービス
  
  
• Utilsは、コードの記述を高速化するのに役立つカテゴリ（ヘルパー）です。
  
  
• 設計要素 -以下で構成されるすべての設計要素：
  
  
  • すべてのセルのxib ：
  • cell-これらのセルのクラス
  • ビューモデル 。

新しいアプリケーションごとに、次を追加する必要があります。

• 画面モジュールのオーバーライド-Coreフレームワークの画面をオーバーライドします。
  
  
• 新しい画面モジュール —これらの機能がどこでも再利用されない場合の新しい画面 。
  
  
• サービスのオーバーライド -通常、すべての国のAPIが完全に同一に機能するわけではないため、ネットワークサービスを再定義する必要があります。
  
  
• xib-セルの新しいデザインを開発する必要がある場合があります。
  
  

通常、すべてのセルはコアから取得されます。 View-Modelを使用してデザインをカスタマイズできます。これらは非常に普遍的であり、最終的にデザインはLegoの形式になります。







その結果、このような「フランケンシュタイン」が得られます。

例

これは同じ画面ですが、国が異なります。 共通の基本実装、つまりCoreでプログラミングされています。 花や写真のさまざまなカテゴリを通じてデザインの違いを実現しています。 よく見ると、次のような10の違いを見つけることはほとんどできません。

1. 異なる写真、リソースの異なる国では、同じ名前の異なる写真があります。
   
   
2. 電卓の異なる背景。
   
   
3. 情報の異なる配置とわずかに異なるフォント。
   
   
4. ボタンの異なる色
   
   

2番目のタイプの画面は、すでにより複雑です。 左側はコアフレームワークの基本的な実装であり、右側は新しい国の顧客が同じ情報をわずかに異なる方法で表示することにしたものです。 ビジネスロジックは保持されていますが、新しい設計を行う必要がありました。 他のセル（Coreフレームワークからも）を使用し、クレジットカードによる支払いという新しい機能も実装しました。



すべてが順調であるように見え、顧客は非常に喜んでおり、速度を上げて新しい国をより速くすることを提案しました。 しかし、もちろん、すべてを考慮していませんでした。

問題の原因

• 新しい開発者
  
  

プロジェクトの勢いを増すために、新しい開発者が採用されました。

• 共有リソース
  
  

すでに述べたように、すべての国に共通のリソースがあり、それらはパブリックドメインです。 新しい開発者（または古い開発者でも）は、パラメータを変更したり、共有リソースの要素を移動/変更したりできます。 もちろん、誰もがこれを行うべきではないことを理解していますが、それでも事例はありました。

• デザイナーは、アプリケーションの統一スタイルを忘れていました
  
  

すべてのアプリケーションのスタイルは同じです。たとえば、同じテキスト配置、特定のセルの色、同じ背景などです。 時間が経つにつれて、デザイナーはこの単一のスタイルを忘れ始め、ベースセルのスタイルを変更できるようになりました。 しかし彼は、そうすることで、まったく別のアプリケーションに害を及ぼす可能性があるとは考えていませんでした。 そして、それに関与している開発者も、彼が被害を受けたことを知りませんでした。 その結果、手動テスト中に、「左」設計に常にいくつかの問題がありました。



これらの問題の解決策は、Ulテストの導入であることがすぐにわかりました。 Ulテストを導入する前に、iOSプロジェクトでこれを行うことができるツールの市場について少し分析しましたが、他のプラットフォームについては考慮しませんでした。

Ulテストツール：

• AppleのiOS Ulテスト
  
  
• appiumは現在、さまざまなオペレーティングシステム用の統一されたテストを記述するための最も人気のあるフレームワークです。 一般的なテストを作成して、さまざまなプラットフォームにエクスポートできます。
  
  
• Calaba.sh -Xamarinが開発したオープンフレームワークには、さまざまなプラットフォーム用の一般的なテストの作成も含まれます。
  
  

明確な基準に従って分析を行いました。

1. コスト。 機能なしの基本構成のすべての製品は無料で、開発者はプロジェクトに固定して使用できます。
   
   
2. クロスプラットフォーム 。 これは私たちにとってそれほど重要ではありませんでしたが、分析ではこの基準を考慮しました。
   
   
3. コード生成、つまりテスト記録の可能性-UI要素との対話中に、テストのコードが生成されます。
   
   

AppleとAppiumにはそのようなツールがありますが、Calaba.shは基本構成にはありませんが、この機能を購入できるXamarinクラウドがあります。 また、テストを実行できる2,000を超えるデバイスを提供します。 テストの記録は、常に非常に良いとは限りません。 手で何も書かないと、何が生成されるのか理解できないことがあります。 このようなツールがないことはプラスになります。 これについては少し後で説明します。



4.プロジェクトの前に、チームのメンバーがツールを使用した経験 。



私たちのチームの全員が1つのツール（Apple）だけを使用しました。 より正確には、彼らは彼について何かを知っていました。 全員がこのツールに満場一致で投票しました。 原則として、それが提供する機能が欠けていたため、他のプラットフォームはそれほど重要ではありませんでした。



彼についてもう少しお話しします。



iOS Ulテストは、2015年に導入されたかなり新しいテクノロジーです。 次の2つのことに基づいています。

• XCTest-テストを作成して実行できるフレームワーク。
  
  
• アクセシビリティ-障害のある人がAppleデバイスを完全に使用できるようにします。 UIテストの場合、UIテストの実行中にUI要素と対話する機能を提供します。
  
  

XCTestは3つのクラスのみに基づいています。

1. XCUIアプリケーション-アプリケーションとテストの間の一種のプロキシ。
   
   
2. XCUIEIement-画面上のUI要素。
   
   
3. XCUIEIementQuery-何らかの基準で画面上にある要素を検索するリクエスト。
   
   

デモUIテストの記録

それは簡単です-関数にカーソルを置き、レコードをクリックします。 UIテストが開始されます。 要素をクリックすると、コードが生成されます。



彼が生成したものを見てみましょう。

XCUIApplication *app = app2; [app.buttons[@"start"] tap]; XCUIElement *element = [[[[app.otherElements containingType:XCUIElementTypeNavigationBar identifier:@“UIView”] childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element; [element tap]; XCUIApplication *app2 = app; [app2.keys[@"t"] tap]; [app typeText:@“t"]; . . . [app typeText:@"c"]; [app2.keys[@“o"] [element tap];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、彼はいつもそれほどひどいことをしているわけではありませんが、私は正直にデモを3〜4回録音しようとしましたが、いつも同じ間違いに遭遇しました。

1. XCUIアプリケーションは誤って初期化され、ログとinitを作成しませんでしたが、以前は定義されていなかったいくつかの神話的な変数app2と同等でした。 次の画面で、彼は同じことをしました。
   
   
2. アイテムが正しく見つかりませんでした。 要素はAccessibilityNotifierに設定されていたため、この要素を検索する必要がありました。 しかし、彼はこれを見ず、childrenMatchingTypeを単純に検索し始めました。
   
   

UIテスト記録の短所：

1. 多くのコード。
2. 常に読み取り可能なコードではない-多くの
3. 常に機能するコードではありません。
4. 機能の再利用は実装されていません。

UIテストの記録のこれらの欠点は常に見つかるとは限りませんが、UIテストを作成するときは速度が重要です。 すばやく、美しくいくつかの関数を作成したいのですが、同時に、テストレコーディングの後に戻って何かを編集したくありません。 これは通常、自分で書くよりも時間がかかります。

理論から実践へ

最初に遭遇したのは、 スタブマネージャーでした。 これ以前は、プロジェクトに単体テストは実装されておらず、ネットワークとの通信をエミュレートしていませんでした。



テスト記録エラーを繰り返さず、テストをよりクリーンで正確に記述することを選択しました。 Pageオブジェクトパターンはこれを助けてくれました。 それについて知っている人はほとんどいませんが、テストを書くテスターは知っているべきです。



UIテストの実行中にスクリーンショットを撮るためのスナップショットツールを実装しました。テストの実行時にクラッシュしたかどうかを確認するだけでなく、結果を確認して、画面上のデザインを比較しました。



各項目を詳細に検討します。

スタブマネージャー

何らかの理由で、ネットワークエミュレーションの実装は難しいと考えられています。 実際、すべてはNSURLProtocolクラスを使用して非常に簡単に実行されます。 これは、iOSのURLローディングシステムの動作を事前に定義できるクラスです。



すべては2つのアクションで実行されます。

1. NSURLProtocolを継承する独自のクラスを作成します。
2. URL読み込みシステムに登録します。

アプリケーションでネットワークにリクエストを送信すると、ブートシステムはまずNSURLProtocolが登録されているかどうかを確認します。 もしそうなら、彼女は自分の順番でそれぞれに頼り、このリクエストを処理することが可能かどうか尋ねます。 「はい」と言うと、ネットワークへのリクエストが終了し、アプリケーションレベルで処理されます。

カスタムクラスNSURLProtocol

再定義する必要があるのは3つのメソッドのみです。

1. このリクエストを処理できますか（trueまたはfalseを返すだけです）：
   
   
   
   

    +(BOOL)canInitWithRequest:(NSURLRequest *)request
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. startLoadingメソッド自体。データ置換のすべての魔法が発生します。
   
   
   
   

    -(void)startLoading
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. 最後に、リクエストの処理が終了したことをシステムに伝えます。
   
   
   
   

    -(void)stopLoading
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

すべての魔法が起こるstartLoadingについてもう少し。

 (void)startLoading NSData *cachedData if (cachedData) { NSHTTPURLResponse *response [self.client URLProtocol: didReceiveResponse: cacheStoragePolicy:]; [self.client URLProtocol:self didLoadData: cachedData]; [self.client URLProtocolDidFinishLoading: self]; } else { [self.client URLProtocol: self didFailWithError:   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

内部では、キャッシュ(NSData *cachedData)



からデータを取得します。 私たちの場合、テストケースごとに同じリクエストに対する異なる回答が存在する可能性があるため、それらは異なるバンドルに保存されます。 そのようなデータがある場合は、独自のカスタム応答を作成してシステムに渡し、キャッシュされたデータを返すと言います。



このデータが見つからなかった場合は、カスタムエラーを作成するだけで、ネットワークから送信されたようにリクエストに戻ります。



スタブマネージャーでは、クラスのみを登録します。 これは以下を介して行われます。

 NSURLSessionConfiguration setProtocolClasses: @[[MyNSURLProtocol class]]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが非常に迅速かつ簡単に行われ、機能します。 だからこれを恐れないでください。

ページオブジェクトパターン

私が言ったように、私たちはテスト記録のマイナス面と戦い、UIテストを書くためにより責任あるアプローチを取ることを決めました。 コードをきれいにしようとし、Pageオブジェクトパターンを適用しました。







これは非常に単純で、テストとテストが記述された画面の間に、再利用された機能が実装されているレイヤーが必要であるという事実に基づいています。 つまり、要素とのすべての複雑な相互作用、および画面上の要素のすべての検索がそこで保護されます。



ページオブジェクトパターンの利点：

• コードの読みやすさ。
  
  
• 機能の再利用。
  
  
• ユーザーインターフェイスの一元化。
  
  

私たちのアプローチ

各画面にレイヤーを書くのは不要だと判断しました。 XCTestUtilsと呼ばれる3つのコンポーネントで構成される、アプリケーション全体の一般的なレイヤーのみを作成しました。

1. 画面上のアイテムの検索が保護されるFFElementsクラス。 キーによる検索とインデックスによる検索の2つの機能を実装しています。
   
   
   
   

     @interface FFElements : NSObject -(XCUIElement *)objectForKeyedSubscript:(NSString *)key; -(XCUIElement *)objectAtIndexedSubscript:(NSUInteger)index; @end
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. XCTestCaseのカテゴリ（要素）。 ここでは、UIテストを記述するために必要な特定のFFElementを示しました。セル、ラベル、ボタン。 テキストフィールド。
   
   
   
   

     @interface XCTestCase (Elements) @property (nonatomic,readonly) FFElements *textFields; @property (nonatomic,readonly) FFElements *buttons; @property (nonatomic,readonly) FFElements *labels; @property (nonatomic,readonly) FFElements *cells; -(void)wait:(NSTimeInterval)interval; @end
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
3. textFieldsの操作に役立つXCUIEIementの小さなカテゴリ：
   
   
   
   

     @interface XCUIElement (Utils) @property (nonatomic) NSString *pasteText; +(void)forceTap; @end
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

デモで見たように、textFieldsにテキストを入力するために、各ボタンをクリックするためのコードが生成されます。 forceTap機能-長押しを導入しました。 textFieldsをクリックすると、「Paste text」または「Copy」ボックスが表示されます。



それはクールになり、誰もが幸せでした。

デモ

Pageオブジェクトパターンの使用方法に関する小さなデモを示します。





プロパティFFElementsを介して、特定のタイプの具象要素にアクセスし、それらと対話するメソッドを呼び出します。 textFieldsは次のように操作します：クリックして長押しし、テキストを貼り付けます。 わかりやすく、読みやすく、そして最も重要なのは、6行だけでした。

スナップショット

UIテストを実行し、デバイス上で実行しますが、デザインがうまくいかないことがわかります。 そして、それを見ることができます。



そのため、スナップショットのようなツールを導入することにしました。 これはFastlaneツールグループの一部であり、非常にシンプルで実装が簡単であり、大きなメリットがあります。



スナップショットの利点：

• スクリーンショットを撮ります。
  
  
• UIテストを実行し、適切な場所でスクリーンショットを撮ります。
  
  
• 端末から実行されるため、CIと簡単に統合できます。
  
  

スナップショットを文字通り実装するには、3つのステップが必要です。

1. ターミナルで、fastlane snapshot initコマンドを入力します。 その後、Snapfileというファイルが生成されます-これが構成ファイルです。
   
   
2. Snapfileを構成します。
   
   
3. スクリーンショットを取得したい場所を示します。
   
   

スナップファイル

通常、UIテストを実行するすべてのデバイスを指定でき、スクリーンショットは異なるデバイスの同じ場所で撮影されます。

  devices ([ "iPhone 6s" ]) scheme: "our scheme" output_directory: "./path/." stop_after_first_error: Bool reinstall_app: Bool clear_previous_screenshots: Bool Erase_simulator: Bool languages ([ "en-US" ])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、UIテストを実行するスキーム、すべてのスクリーンショットの結果が保存されるフォルダー、および補助設定を示します。



UIテストを実行する言語を指定することもできます。 ローカライズ版が多数ある場合は、ここですべてのローカライズ版を指定し、出力で異なる言語のスクリーンショットを取得できます。

スクリーンショットの時間

技術的な観点からは、コード自体に特定のファイル-SnaphotHelperを追加するだけです。 テストでターゲットに迅速に。 このファイルはプロジェクトフォルダーに生成されます。fastlanesnapshot initを実行するときは、ターゲットに配置するだけです。



次に、スクリーンショットを撮り、そこでXCUIアプリケーションを転送するすべてのテストケース内で、 setup（）メソッド内で[Snapshot setupSnapshot：app]を呼び出します。



最後に残っているのは、スクリーンショットを撮りたい場所でコードを実行し、写真を生成するスクリーンショットの名前を指定することです[スナップショットスナップショット：@ "Name screen" waitForLoadingIndicator：YES] 、ターミナルから実行し、fastlaneスナップショットを作成して満足します。



テストに合格すると、異なる画面の写真だけでなく、HTMLページが生成されます。







その上で、すべての画像は、たとえば、デバイスごと、およびSnapfileで指定したローカライズごとに、カテゴリに分類されます。 確かに、唯一のマイナスは、これらのすべてのスクリーンショットが実行の順序ではなく名前でソートされることです。

注意してください！

UIテストの実装を決定する前に、いくつかの点に注意する必要があります。

1. スタブマネージャーを恐れる必要はありません。100％実装する必要があります。 実際のネットワークでは、テストは良くありません。
   
   
2. ページオブジェクトパターン -コードがUIテスト用に作成されている場合でも、コードの純度のために戦う必要があります。
   
   
3. スナップショットツールを簡単に実装できます。 すべてのテストケースの準備が整っている場合、すべてのコードが記述されます。これは正午までに行われます。
   
   

このプロジェクトでは、次の利点がありました 。

• 設計バグの数をほぼゼロに減らしました。
  
  
• アプリケーションのすべてのスクリーンショットを迅速に生成するツールと、CIとの統合テストを実装しました。
  
  
• アプリケーションで正しいルーティングを確認しました。
  
  

私はこれについては話しませんでしたが、かなり複雑なルーティングがあります。 国によって異なる場合があります。 新しい画面ごとに、この画面のみにある特定の要素をチェックします。それがない場合は、間違った場所にいる、何かが間違っていることを意味します。 そのため、ルーティングを確認します。



しかし、いくつか短所もありました：

• UIテストの実装期間 。 基本的なフレームワークを作成します。Pag​​eオブジェクトパターンを実装し、Snapshot、Stub Managerを実装します-これは非常に迅速に行われますが、テストケースとデバッグの検討に時間がかかります。
  
  
• また、リファクタリング時にテストをサポートする必要があります。 私たちの場合、これは非常に頻繁に行われます。 もちろん、これに費やす時間はあまりありませんが、忘れないでください。
  
  

約束どおり、最後に、UIテストを実装する価値がある場合に考えます。

使用テストは価値があります：

1. 長期プロジェクトがある場合-100％UIテストを実装する必要があります。 製品を絶えず開発している場合は、設計の品質にも責任を負う必要があります。
   
   
2. Pixel Perfectについて対話を行い、「何かがそこに行きました」という言葉ではなく、アプリケーション全体のスクリーンショットを提供して、修正が必要なものを確認できるようにします。
   
   
3. アプリケーションに複雑なナビゲーションロジックがある場合は、UIテストも実装する必要があります。これは非常に役立ちます。 設計にあまり注意を払うことさえできませんが、ナビゲーションをチェックするためのロジックの実装は非常に簡単です。
   
   

ニュース



今年、モバイル開発に関する会議を別のイベントに移行することにしました。AppsConfMoscowは完全に別のイベントになり、10月8日と9日に開催されます。 ロシア最大のモバイル開発イベントを開催し、全国のすべてのモバイル開発者コミュニティから活動家を集め、500人以上に60以上のレポートを提示する予定です。



しかし、 RIT ++フェスティバルでは、多くの多面的な関連レポートがあります。たとえば、次のアプリケーションを受け取りました。



モバイルDevOps：モバイル開発のプロセスを自動化し、改善します / Vyacheslav Chernikov（Binwell）



Mail.ru / Egor Utrobin（Mail.ru） のフロントエンドのマイクロサービス



Scala / Yuri Badalyants（2GIS） でのマイクロサービスの統合テスト



ただし、PCが1か月間動作するアプリケーションのリストを調べ、興味がある場合はチケットを予約します。