翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# カスタムテスト環境実行のベストプラクティス
<a name="custom-test-environments-best-practices"></a>

 以下のトピックでは、Device Farm でカスタムテスト実行を使用するための推奨ベストプラクティスについて説明します。

**実行設定**
+  テスト仕様ファイルのシェルコマンドを介して同様の設定を適用するのではなく、可能な限り** Device Farm マネージドソフトウェアと API 機能を使用して実行**設定を行います。これには、テストホストとデバイスの設定が含まれます。これは、テストホストとデバイス間でより持続可能で一貫性があるためです。

   Device Farm では、テストを実行するためにテスト仕様ファイルを必要なだけカスタマイズすることをお勧めしますが、カスタマイズされたコマンドが追加されると、テスト仕様ファイルは時間の経過とともに維持が困難になる可能性があります。Device Farm マネージドソフトウェア ( などのツール` devicefarm-cli`と で利用可能なデフォルトのツールを使用`$PATH`) と マネージド機能 ( [https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy) リクエストパラメータなど) を使用して、メンテナンスの責任を Device Farm 自体に移行することでテスト仕様ファイルを簡素化します。

**テスト仕様とテストパッケージコード**
+  テスト仕様ファイル**またはテストパッケージコードで絶対パスを使用したり、特定のマイナーバージョンに依存したりしないでください**。Device Farm は、選択したテストホストとそれに含まれるソフトウェアバージョンに定期的な更新を適用します。特定のパスまたは絶対パス ( ` /usr/local/bin/python`ではなく など`python`) を使用したり、特定のマイナーバージョン ( のみNode.js`20.3.1`ではなく など` 20`) を要求したりすると、テストで必要な実行可能ファイル/ファイルを見つけられない可能性があります。

   カスタムテストの実行の一環として、Device Farm はさまざまな環境変数と `$PATH`変数を設定して、テストが動的環境内で一貫したエクスペリエンスを持つようにします。詳細については、「[カスタムテスト環境の環境変数](custom-test-environment-variables.md)」と「[カスタムテスト環境内でサポートされているソフトウェア](custom-test-environments-hosts-software.md)」を参照してください。
+  **テストの実行中に、生成またはコピーされたファイルを一時ディレクトリに保存します。 **本日は、テストの実行中にユーザーが一時ディレクトリ (`/tmp`) にアクセスできることを確認します ( などのマネージドディレクトリを除く`$DEVICEFARM_LOG_DIR`)。ユーザーがアクセスできる他のディレクトリは、使用中のサービスまたはオペレーティングシステムのニーズにより、時間の経過とともに変更される可能性があります。
+  **テスト実行ログを に保存します`$DEVICEFARM_LOG_DIR`**。これは、実行ログ/アーティファクトを追加するためのデフォルトのアーティファクトディレクトリです。それぞれが提供する[テスト仕様の例は、](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example)デフォルトでアーティファクトにこのディレクトリを使用します。
+  テスト仕様の `test`フェーズで**、失敗時にコマンドがゼロ以外のコードを返**すことを確認します。`test` フェーズ中に呼び出された各シェルコマンドのゼロ以外の終了コードをチェックすることで、実行が失敗したかどうかを判断します。ロジックまたはテストフレームワークが、必要なすべてのシナリオに対してゼロ以外の終了コードを返すことを確認する必要があります。これには、追加の設定が必要になる場合があります。

   たとえば、特定のテストフレームワーク (JUnit5 など) では、ゼロテストの実行が失敗と見なされないため、何も実行されていない場合でもテストが正常に実行されたことが検出されます。例として JUnit5 を使用すると、このシナリオがゼロ以外の終了コードで終了`--fail-if-no-tests`するようにコマンドラインオプションを指定する必要があります。
+  **ソフトウェアのデバイス OS バージョンおよびテスト実行に使用するテストホストバージョンとの互換性を確認します**。例えば、テスト対象のデバイスのすべての OS バージョンで意図したとおりに動作しないソフトウェアフレームワーク (Appium) のテストには、特定の機能があります。

**セキュリティ**
+  ** テスト仕様ファイルに機密性の高い変数 (AWS キーなど) を保存またはログ記録することは避けてください。 **テスト仕様ファイル、テスト仕様生成スクリプト、およびテスト仕様スクリプトのログはすべて、テスト実行の最後にダウンロード可能なアーティファクトとして提供されます。これにより、テストランへの読み取りアクセス権を持つアカウント内の他のユーザーのシークレットが意図せず公開される可能性があります。