質問が少し漠然としているので、長い回答を書きます。
public コンストラクターを持たないクラスがあります (NotificationManager など)。
システム全体のリソース/コンポーネント (NotificationManager など) があり、Android ではアプリケーションがオンデマンドで構築/インスタンス化することを好まないため、代わりに、これらのリソースはシステムによって集中管理および管理され、アプリケーションは常にシステム提供の API を使用してそれらを取得する必要があります。 .
Context.getText のようにオーバーライドできないメソッドを持つクラス
通常、Java では、final としてマークされたメソッドは API によって保護されていることを意味し、API 開発者はアプリケーション開発者によってデフォルトの動作がオーバーライドされることを望んでいません。特に、このメソッド Context.getText() では、実際に Template メソッド パターンを使用しています。詳細については、以下の herschel のコメントとソース コードを確認してください。
次に問題は、これらの Android コンテキスト ベースのリソース/コンポーネントを使用して記述されたコードを適切にテストするにはどうすればよいかということです。
Android SDK が提供する答えは Test Project (InstrumentationTestRunner 経由) です。通常、InstrumentationTestRunner を使用する場合、システムは test.apk (テスト プロジェクトからビルド) と app.apk (アプリケーション プロジェクトからビルド) の両方をインストールし、test.apk を使用してテスト用に app.apk を操作します。これは、AndroidTestCase API (下の図では JUnit と呼ばれます) を使用するか、InstrumentationTestCase API (下の図では Instrumentation と呼ばれます) を使用するかに関係なく発生します。対応するテスト可能な Android コンテキスト ベースのリソース/コンポーネント (つまり、Activity、NotificationManager、または TextView) はすべて、実際に実行中の app.apk インスタンスから取得されます。テスト プロジェクトで独自の MockContext を作成/使用する場合、図から、実行中のアプリケーションに InstrumentationTestRunner によってモック オブジェクトが注入されることがわかります。
インストルメンテーション テストを使用することの欠点は効率に関するものです。単一のメソッドから単一のメソッドをテストするだけでよいのに、完全な実行ライフ サイクルに入ります (エミュレーターを開始 -> test.apk と app.apk の両方をインストールして開始し、InstrumentationTestRunner を起動する)。クラス（コメントで述べたように）。私は Ollie に同意します。これは敵対的な設計です。
これがRobolectric の出番であり、彼らの Web サイトからの引用です。Robolectric は、Android SDK jar の牙を剥ぐ単体テスト フレームワークであり、Android アプリの開発をテスト駆動できます。テストはワークステーションの JVM 内で数秒で実行されます。
私自身の経験から、アプリケーションは約 10 のアクティビティといくつかのサービスで構成され、他のカスタム ビュー/ウィジェットは主にリモート サーバーとの HTTP 通信を行い、インストルメンテーション テスト (テスト プロジェクト経由) と Robolectic テスト Android コンテキスト ベースのコードの両方を使用します。時間が許す限り、アプリケーションのほぼすべてのクラス/パブリック メソッドをテストできます。