Google EspressoまたはRobotium [終了]

Automated UIテストツールを使用する必要があり、RobotiumとGoogle Espressoの使用を混同しています。

2つの主な違いは何ですか？一方には存在するが他方には存在しない機能はありますか？

完全な開示：私はEspressoの著者の1人です。

EspressoとRobotiumはどちらもインストルメンテーションベースのフレームワークです。つまり、Android Instrumentationを使用して、テスト中のアクティビティを検査および操作します。

Googleでは、Robotiumを使用することから始めました。これは、ストックインストルメンテーションよりも便利だったためです（Robotium開発者にとっては、そうするのは大変なことです）。ただし、開発者にとって信頼性の高いテストを簡単に作成できるようにするフレームワークへのニーズを満たしていませんでした。

Robotiumに対するEspressoの主な進歩：

1. 同期。デフォルトでは、インスツルメンテーションテストロジックは、UIオペレーション（UIスレッドで処理される）とは異なる（インスツルメンテーション）スレッドで実行されます。テスト操作とUIの更新を同期しないと、テストは不安定になりがちです。つまり、タイミングの問題のためにランダムに失敗します。ほとんどのテスト作成者はこの事実を無視し、一部はスリープ/再試行メカニズムを追加し、さらに少数がより洗練されたスレッドセーフティコードを実装します。これらのどれも理想的ではありません。Espressoは、テストアクションとアサーションをテスト中のアプリケーションのUIとシームレスに同期させることで、スレッドの安全性を処理します。Robotiumは、スリープ/再試行メカニズムでこれに対処しようとしますが、これは信頼性が低いだけでなく、テストの実行が必要以上に遅くなる原因にもなります。

2. API。Espressoには、明確に定義された予測可能な小さなAPIがあり、カスタマイズが可能です。標準のhamcrestマッチャーを使用してUI要素を検索する方法をフレームワークに伝え、アクションを実行するか、ターゲット要素のアサーションをチェックするように指示します。これは、テスト作成者が30以上のクリックメソッドから選択することが期待されているRobotiumのAPIと対照的です。さらに、RobotiumはgetCurrentActivity（現在の意味は何ですか？）やgetViewなどの危険なメソッドを公開しています。これにより、メインスレッド外のオブジェクトを操作できます（上記のポイントを参照）。

3. 障害情報をクリアします。Espressoは、障害が発生したときに豊富なデバッグ情報を提供するよう努めています。さらに、独自のエラーハンドラーを使用して、Espressoによるエラーの処理方法をカスタマイズできます。私はしばらく試していませんが、以前のバージョンのRobotiumは一貫性のないエラー処理に悩まされていました（たとえば、clickOnViewメソッドはSecurityExceptionsを飲み込みます）。

以前の回答とは異なり、Espressoは、多数のユーザーがいるすべてのAPIバージョンでサポートされています（http://developer.android.com/about/dashboards/index.htmlを参照）。古いバージョンの一部で動作しますが、それらをテストするとリソースの無駄になります。テストについて... Espressoは、すべての変更について、包括的なテストスイート（95％を超える範囲）と、Googleが開発したAndroidアプリケーションの大部分によってテストされます。

EspressoはRobotiumよりはるかに高速ですが、一部のSDKバージョンでのみ機能します。

したがって、すべてのデバイスで機能するテストが必要な場合は、Roboitumを使用してください。そうでない場合は、エスプレッソを使用してください。しばらくの間、ベータテスターに​​なることを忘れないでください。