このセクションの内容

全般

コマンド ラインの使用方法をすばやく参照する方法

-help コマンド ライン オプションを使用します。

jtestcli.exe -help

プロキシ経由で Jtest を操作する方法

プロキシ サーバー経由で接続する場合、通常、-D コマンド ライン オプションを使用して JVM にプロトコル固有のシステム プロパティを渡して接続する必要があります。

Jtest を操作する場合、HTTPS プロトコルのシステム プロパティが設定されていることを確認してください。最低でも、https.proxySet=true、https.proxyHost=[hostname]、https.proxyPort=[port number] を設定する必要があります。プロキシ サーバーが認証を要求する場合、https.proxyUser および https.proxyPassword プロパティを使用して認証情報を設定できます。

コマンドは次のようになります。

java -Dhttps.proxySet=true -Dhttps.proxyHost=myserver.example.com -Dhttps.proxyPort=8080 -Dhttps.proxyUser=user1 -Dhttps.proxyPassword=MyPassword

デスクトップで Eclipse または IntelliJ IDEA とともに Jtest を使用する場合、Eclipse または IntelliJ IDEA で指定されたプロキシ設定が自動的に検出され、使用されます。追加の設定は必要ありません。

Mac OS で Java を実行できない場合

「"java" cannot be opened because the developer cannot be verified」というダイアログが表示された場合、次の操作を行います。

1. ポップアップ ダイアログで [Cancel] をクリックします。
2. Mac OS の [System Preferences] に移動し、[Security & Privacy] を選択します。
3. [General] 設定で [Allow Anyway] ボタンをクリックし、Java を有効にします。
4. ダイアログが表示される原因になった Jtest のアクションを再度実行します。 
5. 「macOS cannot verify the developer of "java". Are you sure you want to open it?」というダイアログが表示されたら、[Open] をクリックします。

インストール

マシン ID が変わってしまうのを防ぐ方法

ネットワーク環境が変わると、マシン ID の計算に使用されるインターフェイスが変わり、結果としてマシン ID が一定でなくなる可能性があります。PARASOFT_SUPPORT_NET_INTERFACES 環境変数を使用すると、安定したインターフェイスを指定し、マシン ID が変化するのを防ぐことができます。

1. PARASOFT_SUPPORT_NET_INTERFACES 環境変数を作成します。

2. 変数に安定した Ethernet ネットワーク インスタンスを指定します。仮想インターフェイス、一時インターフェイス、ループバック インターフェイスは使用しないでください。
   - Windows の場合: ネットワーク カードの MAC アドレスを指定します。ipconfig -all コマンドを実行すると、アドレスを取得できます。  例:

   SET PARASOFT_SUPPORT_NET_INTERFACES=00-10-D9-27-AC-85

   - Linux の場合: "inet" または "inet6" ファミリーのいずれかのネットワーク インターフェイスを指定します。ifconfig コマンドを実行すると、利用可能なインターフェイスのリストを取得できます。例: 

   export PARASOFT_SUPPORT_NET_INTERFACES=eth1

問題が解決しない場合、PARASOFT_DEBUG_NET_INTERFACES 環境変数を作成して true を指定すると、診断情報を取得できます。テクニカル サポートに送信可能なチェック手順や、マシン ID の計算に使用されているインターフェイスが標準出力に表示されます。マシン ID の計算に使用されているインターフェイスには [SELECTED] という接頭辞が付きます。

テストおよび解析

Jtest を新しいバージョンにアップデートした後に静的解析のパフォーマンスが悪くなった場合

新しいバージョンの Jtest は、静的解析の実行により多くのメモリを必要とする場合があります。[INSTALL_DIR]/etc/jtestcli.jvm 設定ファイルで -Xmx オプションを設定することで、メモリの割り当てを増やすことが出来ます。

Maven でプロジェクトをビルドしたとき、Jtest がコンパイルの問題をレポートする

Jtest が Maven テスト スコープの依存関係のインポートに関するコンパイルの問題をレポートした場合、mvn test コマンドで jtest:jtest ゴール を実行してください。

mvn test jtest:jtest

jtest:coverage ゴール (Maven) または jtest-coverage タスク (Gradle) を実行するとビルドが失敗する

Jtest の coverage ゴール/タスクはリリース 10.2.2 (プラグイン バージョン 1.2.4) で削除され、利用できなくなりました (「10.x から 10.2.2 以降への移行」を参照)。このゴールを実行すると、次のメッセージでビルドが失敗します。

[ERROR] Could not find goal 'coverage' in plugin com.parasoft.jtest:jtest-maven-plugin.(Maven)

Task 'jtest-coverage' not found (Gradle)

Jtest でテスト影響分析を実行するよう設定したとき、Gradle のビルドが失敗する

Jtest を使用してマルチモジュール プロジェクトのテスト影響分析を実行する場合、サブモジュールにテスト影響分析時に影響を受けるテストとして検出されるテストがないと、Gradle のビルドが失敗する場合があります。テストが検出されなかった場合に Gradle のビルドが失敗するのを防ぐには、次のオプションを設定します:
setFailOnNoMatchingTests(false)

Jtest が Gradle によるテスト実行からカバレッジを収集できない場合

カバレッジの収集を可能にするため、Jtest は Jtest カバレッジ エージェントの JVM 引数を自動的に設定します。これらの引数を上書きすると、Jtest はカバレッジ データを収集できません。Gradle のビルド スクリプトで JVM 引数を変更している場合、上書きを防ぐために、(+=) で他の引数に追加されていることを確認してください。

Maven を使用したテスト影響分析が、コードの変更の影響を受けないテストを再実行する

• テスト影響分析は、テスト スイート内の少なくとも 1 つのテストがコードの変更の影響を受ける場合、テスト スイート全体を再実行します。結果として、テスト スイートに影響を受けないテストが含まれている場合、それらも再実行されます。
• まれに、テスト影響分析がインクルードまたはエクスクルード パターンを認識できない場合があります。  回避策としては、手動でテストをフィルタリングできます。詳細は「再実行するテストを手動でフィルタリングする」を参照してください。

テキスト ストリームの先頭にバイト オーダー マーク (BOM) が現れるソース ファイルをテストする方法

BOM を含むファイルが適切に処理され、テストされるようにするには、ファイルをパースするときに BOM を削除するよう Jtest を設定します。jtest.properties 設定ファイルに以下のいずれかの設定を追加します。

• jtest.parser.bom=remove - BOM を削除し、元のファイルのエンコーディングを変更しません。
• jtest.parser.bom=recognize - BOM を削除し、元のファイル エンコーディングを BOM によって定義されたエンコーディングで上書きします。

Maven または Gradle でのテスト実行時に Jtest が不安定なテストを失敗としてレポートする場合

デフォルトでは、Jtest は実行時に常に失敗するテストと成功したり失敗したりするテスト (不安定なテスト) を区別しません。 非推奨の XML 処理メカニズムを使用したテスト実行を有効にすると、不安定なテストを認識するよう設定できます。 それには、jtestcli.properties 設定ファイルに次のオプションを追加します。

jtest.unittest.xml.results.processing.enabled=true

非推奨の XML 処理メカニズムを有効にすると、テスト実行が遅くなる可能性があることに注意してください。

mockito-inline とともに PowerMock を実行したときにテストが失敗する場合

クラスパスで powermock の前に mockito-inline がある状態で PowerMock テストを実行すると、次の例外でテストが失敗する場合があります。

NotAMockException: Argument should be a mock, but is: class java.lang.Class

これは、PowerMock が mockito-inline のモック メーカーと連携する際の問題によって発生します (詳細は「PowerMock の問題」を参照)。 

ユーザーの要件に応じていくつかの解決策があります。

• クラスパスから mockito-inline を削除するか、powermock を先にします。Mockito を使用した static メソッドおよびコンストラクターのモックが必要ない場合は、このオプションを選択できます。
• PowerMock ステートメントをアップデートし、mockito-inline を正しくサポートするメソッド呼び出しを使用します。一部の PowerMock ステートメントにはクリーン アップデート パスがなく、回避策が必要になります。サンプルを参照してください:
  • PowerMock テストのアップデート (static モック) - サンプル
  • PowerMock テストのアップデート (検証) - サンプル
• mockito-inline を使用した Mockito の static および コンストラクター モックに切り替えますこれには、相当する Mockito API を使用して Powermock の呼び出しを書き換える必要があります。サンプルを参照してください:
  • PowerMock テストの Mockito への書き換え (static モック) - サンプル
  • PowerMock テストの Mockito への書き換え (コンストラクターのモック) - サンプル

モックできるクラスおよびメソッドに関して一部制限があります。詳細は、「Mockito による static およびコンストラクターのモックの制約」を参照してください。

PowerMock テストのアップデート (static モック) - サンプル

次の PowerMock の呼び出しは、容易に修正可能な問題を発生させます。

• thenReturn()
• doReturn()
• doNothing()

例:

PowerMockito.when(MyClass.staticCall(any())).thenReturn("value"); PowerMockito.when(MyClass.staticCall(any())).thenReturn("value1", "value2"); PowerMockito.doReturn("value").when(MyClass.class); MyClass.staticCall(any()); PowerMockito.doNothing().when(MyClass.class, "staticCall", any());

アップデート後のコード:

PowerMockito.when(MyClass.staticCall(any())).thenAnswer(invocation -> "value"); PowerMockito.when(MyClass.staticCall(any())).thenAnswer(invocation -> "value1").thenAnswer(invocation -> "value2"); PowerMockito.doAnswer(invocation -> "value").when(MyClass.class); MyClass.staticCall(any()); PowerMockito.doAnswer(invocation -> null).when(MyClass.class, "staticCall", any());

PowerMock テストのアップデート (検証) - サンプル

verifyStatic() または verifyPrivate() を呼び出した場合、次のテスト例外が発生する可能性があります。

org.mockito.exceptions.misusing.NotAMockException: Argument passed to verify() is of type Class and is not a mock! Make sure you place the parenthesis correctly! See the examples of correct verifications: verify(mock).someMethod(); verify(mock, times(10)).someMethod(); verify(mock, atLeastOnce()).someMethod();

コードをリファクタリングし、手動で必要な呼び出しを検証する必要があります。 

例:

PowerMockito.when(MyClass.staticCall(any())).thenAnswer(invocation -> "value"); ... PowerMockito.verifyStatic(MyClass.class, times(1)); MyClass.staticCall(any());

アップデート後のコード:

int counter[] = new int[]{0}; PowerMockito.when(MyClass.staticCall(any())).thenAnswer(invocation -> { counter[0]++; return "value"; }); ... assertEquals(1, counter[0]);

verifyPrivate() の場合、Mockito は private メソッドのモックをサポートしていないため、唯一の解決方法は、必要な呼び出しを手動で検証することです。

例:

PowerMockito.mockStatic(MyClass.class); PowerMockito.when(MyClass.class, "privateStatic", any()).thenAnswer(invocation -> inv.callRealMethod()); ... PowerMockito.verifyPrivate(MyClass.class, times(1)).invoke("privateStatic");

アップデート後のコード:

PowerMockito.mockStatic(MyClass.class); int counter[] = new int[]{0}; PowerMockito.when(MyClass.class, "privateStatic", any()).thenAnswer(invocation -> { counter[0]++; return inv.callRealMethod(); }); ... assertEquals(1, counter[0]);

PowerMock テストの Mockito への書き換え (static モック) - サンプル

PowerMock のコード:

PowerMockito.mockStatic(MyClass.class); PowerMockito.when(MyClass.staticCall(any())).thenReturn("value"); // test code PowerMockito.verifyStatic(MyClass.class, times(1)); MyClass.staticCall(any());

Mockito に変換後のコード:

try (MockedStatic<FunctionsToMock> mocked = mockStatic(FunctionsToMock.class)) { mocked.when(() -> FunctionsToMock.staticCall(any())).thenReturn("value"); // test code mocked.verify(() -> FunctionsToMock.staticCall(any()), times(1)); }

PowerMock テストの Mockito への書き換え (コンストラクターのモック) - サンプル

PowerMock のコード:

FunctionsToMock mock = Mockito.mock(FunctionsToMock.class); PowerMockito.whenNew(FunctionsToMock.class).withAnyArguments().thenReturn(mock); when(mock.calculate()).thenReturn(1); // test code

Mockito に変換後のコード:

try (MockedConstruction<FunctionsToMock> mocked = mockConstruction(FunctionsToMock.class, (mock, context) -> { when(mock.calculate()).thenReturn(1); })) { // test code }

Mockito による static およびコンストラクターのモックの制約

以下のケースは Mockitoではサポートされていません。

• private メソッドは、Mockito ではモックできません。
• Mockito の内部構造と干渉しないよう、次のクラスは static およびコンストラクター モック化されません。
  • java.lang.ClassLoader
  • java.lang.Thread
  • java.lang.Object
  • java.lang.System
  • java.util.Arrays
  • java.util.Locale
  • java.util.concurrent.ConcurrentHashMap
  • 抽象クラス

Mockito は JDK のクラスを static モックすることも推奨していません。

• これらのクラスをモックすると、スタック オーバーフロー例外やその他の無限ループが発生する可能性があります。
  • java.io.File

ソース管理システムとテスト入力でファイルの名前が違っているためにファイルをテストできない場合

ファイルを適切に処理し、解析するには、 Jtest がテスト スコープのファイル名 (プロジェクト内のファイル名) とソース管理システムのファイル名を照合できなければなりません。そのため、Git などの大文字と小文字を区別するソース管理システムを使用している場合は、ファイル名の大文字/小文字も同一であることを確認する必要があります。

レポート

Jtest レポートで一部の文字が正しく表示されない場合

IDE での操作

UTA ファイルへのパスが 250 文字を超えるとテスト実行が失敗する

Windows では、パスが 250 文字より長いとファイルにアクセスできない場合があります。ネストされたフォルダー構造の深い場所にワークスペースがある場合、UTA ファイルへのパスが 250 文字を超える可能性があります。テスト実行の鍵になるファイルにアクセスできない場合、実行は失敗します。

UTA ファイルへのパスが制限を超えないよう、フォルダー階層のより上にワークスペース フォルダーを移動することを検討してください。

IntelliJ IDEA で Jtest のラン コンフィギュレーションが動作しない場合

一部の IntelliJ バージョンの既知の問題により、まれに、Jtest のラン コンフィギュレーションが動作しないケースがあります (詳細は https://youtrack.jetbrains.com/issue/IDEA-223124 を参照)。この問題が発生した場合、IDE を再起動する必要があります。再起動後、Jtest のラン コンフィギュレーションは正常に動作するようになります。

Ubuntu Linux で HTML コンテンツ (Jtest のルール ドキュメントやレポートなど) を参照できない場合

最新の Ubuntu Linux (21.10 以降) を使用している場合、 デフォルトの Snap ベースの Firefox ブラウザーでは、Eclipse IDE が HTML コンテンツを正しく表示できない場合があります (https://github.com/eclipse-platform/eclipse.platform.swt/issues/221 を参照)この場合、次の 2 つの回避策があります。

• 非 Snap 版の Firefox (または他のブラウザー) をインストールし、システムのデフォルトのブラウザーとして設定します。
• Eclipse の [Preferences] > [Preferences] > [Web Browser] > [External web browsers] で「外部の Web ブラウザー」を使用するよう設定します。

注意: Firefox を「外部の Web ブラウザー」として設定する場合、次の設定を使用します:
Location: /usr/bin/env
Parameters: firefox %URL%