AppiumとCalabashは、Androidアプリケーションのテストを自動化するための最も一般的なフレームワークの一部です。 もちろん、それぞれに長所と短所があります。 主な制限は次のとおりです。
Calabash:テストアプリケーションの一部であるユーザーインターフェイスのみを制御できます。特に、通知のテストはサポートされていません。
- Appium: Calabashなどのアプリケーションでバックドアメソッドを呼び出すことはできません(これらのメソッドは、テスト対象のアプリケーションの状態を設定するのに非常に役立ちます)。
Badooの私たちは、Appiumが始まったばかりのときにテストを自動化するためにCalabashを使用しました。 これは非常に安定したツールであり、Appiumよりも高速であるため、移行しません。 しかし、Badooなどの多機能アプリケーションを自動化するために、テストアプリケーションインターフェイスでのみ動作するというCalabashの制限をバイパスする必要がありました。
私たちがそのような決定に来たとき。 そして、それはまだ動作しますが、Androidの異なる対角線、異なるバージョンなどのデバイスの多くのバリエーションのために、その信頼性は低下します。
この記事では、UIAutomator2サポートをCalabashに追加することで問題を解決した方法を説明します。 焦りすぎている場合は、最後にすぐに使えるRuby Gemへのリンクがあるという秘密を伝えます。
問題認識
Calabash-Androidの高レベルアーキテクチャを見てみましょう。
Calabash-Android-ServerはRobotiumフレームワークを使用し、RobotiumフレームワークはAndroid Instrumentationフレームワークを使用してアプリケーションを制御します。 インスツルメンテーションにより、Robotium(およびCalabash)がランタイムにアクセスできるようになり、アプリケーションインターフェースを制御し、外部からメソッドを呼び出すことができます。
ただし、Robotiumが制御できるのは、アプリケーションコードの一部であるユーザーインターフェイスのみです。 AppiumはUIAutomatorを使用するため、このような制限はありません 。
問題解決
Google Instrumentationフレームワークは、テスト用のAndroidヘルパーライブラリの一部です。 アプリケーションのコンテキストで機能し、システムとアプリケーションのすべての相互作用を表示するため、それらを管理できます。 Instrumentationに基づいて、RobotiumやEspressoなどの一般的なテストフレームワークが構築されます。
さらに、RobotiumはCalabash-Androidのサーバー側で使用されるため、計測情報にアクセスできます。 また、UIAutomator 2.0は当時Instrumentationの一部となり、Calabash-Androidサーバー内で使用できるようになりました。
CalabashInstrumentationTestRunnerを使用して、Ruby CalabashクライアントはADBを介してInstrumentationを起動します。 Calabashサーバーでは、CalabashInstrumentationTestRunnerはInstrumentation Androidクラスの拡張です。 これはRobotium Soloに渡されるInstrumentationオブジェクトです。 UIAutomator 2のおかげで、デバイス全体を制御できる新しいUIDeviceオブジェクトの作成に使用できます。
これは私が問題の解決に来た方法です:
1)UIAutomatorライブラリをCalabash-Androidサーバーに追加しました
Calabash-Android-Serverプロジェクトを複製し 、uiautomator2 JARをlibフォルダーに追加しました。
2)UIDeviceオブジェクトをインストールしました
InstrumentationBackend.java
ファイルで、UIAutomatorからUIDeviceオブジェクトをインスタンス化するメソッドを作成しました。
public static UiDevice getUiDevice() { if (instrumentation.getUiAutomation() == null) { throw new NullPointerException("uiAutomation==null: did you forget to set '-w' flag for 'am instrument'?"); } if(uiDevice == null) { uiDevice = UiDevice.getInstance(instrumentation); } return uiDevice; }
3)UIAutomator2 APIを使用した新しいコマンドを追加しました
Calabash-Android-Serverに新しいコマンドを追加するのは簡単です。 Rubyコードで使用するすべてのコマンドは、Actionsインターフェイスにマッピングされます。
sh.calaba.instrumentationbackend.actions
通知パネルを開くアクションを実装しましょう:
public class PullNotification implements Action { @Override public Result execute(String... args) { InstrumentationBackend.getUiDevice().openNotification(); return new Result(true); } @Override public String key() { return "pull_notification"; } }
この例では、key()メソッドを使用して、Calabash Rubyクライアントが使用するコマンドに名前を付けています。 クライアントがこのコマンドを呼び出すと、execute()メソッドが呼び出されます。
4)-wフラグを使用して測定(計装)を開始しました
https://github.com/calabash/calabash-androidからRubyクライアントを複製しました 。 lib/calabash-android/operations.rb
にパッチを適用し、ADBコマンドを使用して測定を開始する-wフラグを追加しました。 これを行う方法は 、このコミットで確認できます 。
上記の例は私のフォークで見ることができます:
実例:
通知バーを拡張していずれかを開く方法を見てみましょう。
上記のフォークから両方のリポジトリを同じレベルのディレクトリに複製します。
git clone
https://github.com/rajdeepv/calabash-android
git clone
https://github.com/rajdeepv/calabash-android-server
両方のリポジトリで、
'uiautomator'
ブランチに切り替えます。
calabash-androidリポジトリのruby-gemフォルダーに移動し、
bundle exec rake build
を使用してRuby Gemをbundle exec rake build
ます。
このgemをプロジェクトに含めます。
start_test_server_in_background
をstart_test_server_in_background(with_uiautomator: true)
ます。
通知パネルのプルコマンド:
perform_action('pull_notification')
。
- 既知のテキストフラグメントで通知に「タッチ」するには、
perform_action('uiautomator_touch_partial_text', 'my partial text')
Ruby Gemを使用する準備ができました:
これらすべてを行いたくない場合は、 完成したgemをダウンロードして、最後の3つのポイントに従うだけです。
おわりに
Calabash-Android-Serverコードをより深く掘り下げ、それがどのように機能するかを理解し、問題を解決する方法を探求するのに、いくらかの努力が必要でした。 最初の試みではこれを行うことはできませんでしたが、その過程で計装の秘密のいくつかを学びました。 いつかあなたと共有します。
この例は、Calabashを使用してプッシュ通知を自動化することを目的としていますが、Calabashベースの自動化フレームワークで発生するすべてのタスクに同じアプローチを適用できます。
ホーム画面アプリケーションのウィジェットをテストします。
Androidアプリケーションのダイアログボックスを使用した完了アクションを使用したインテント処理。
- アプリケーションから実行されているサードパーティアプリケーションとの相互作用をテストします。
この投稿がCalabashを使用してアプリケーションのインターフェイスを操作する以上の状況をテストするのに役立つことを願っています。 ご質問やその他のフィードバックがある場合-コメントを歓迎します。