特定のハードウェアに依存するアプリケーションをテストするにはどうすればよいですか

Androidアプリケーションを作成しました。アプリケーションには、非常に特定のハードウェア（現在はプロトタイプ）へのBluetooth接続が必要です。現在アプリをテストできる唯一の方法は、何百マイルも走行して機能するかどうかを確認することです。最終的にANRが発生した場合、クライアントの前では非常に恥ずかしいことがあります。このアプリの接続タイプとメカニズムは、このハードウェアに合わせて非常に厳密に調整されています。ラップトップを持参したり、電話をルート化したり、敷地内の他のデバイスに接続したりすることは許可されていません。

このアプリケーションを自宅でテストする方法、またはアクティビティをステップ実行して、クライアントが私を怖がらせている間、2番目のアクティビティで別のANRがないことを確認する方法はありますか？

私は経験豊富なプログラマーではないことを指摘しておく必要があります。これは、現在スタッフを雇っていないため、誰かを助けるための新しいアイデアです。間違いなく、これを開発するための非常に基本的な概念の一部が欠けています。

@ MrSmith42が示唆したように、インターフェイスを模擬するために最善を尽くす必要があります。モックするために実際のBluetooth接続は必要ありません。インターフェイスを呼び出します。そのインターフェースは、デバッグで、特定の入力に対して期待するものを送信します。デバッグ中でない場合、データの送受信という実際の作業を実行します。インターフェースに送信するものとその出力の処理方法が機能することを確認してください。寛大なエラー処理を散布し、管理できるエラーを管理し、残りをログに記録すると、クライアントで直接テストできるものが得られます。

その時点でのエラーの唯一の可能性は、デバイスが処理することを期待する方法と実際に動作する方法の違いにあり、私の経験では、ハードウェアが完全に信頼できるとは決して言えません。したがって、少なくともある種のログをダンプすることになると予想されないものに対して、包括的なエラー処理メカニズムを用意してください。

これはプロジェクト管理の問題であり、ソフトウェア開発の問題ではありません。

デバイスの基本的な動作を評価し、ソフトウェアとどのように相互作用するかを確認するには、デバイス（クライアントの敷地内またはオフィス）に1〜2週間アクセスできる必要があります。その後、インターフェースをモックして自宅で機能を開発し、再び1週間の統合テストを行うことができます。

ハードウェアとやり取りする場合、統合テストの必要性と価値を過小評価することはできません。統合テストが不可能な場合、プロジェクトは失敗します。テストできないハードウェアに対して盲目的にプログラミングすることはできません。

この問題についてクライアントと話し合う必要があります。