このセクションの内容

全般

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

-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

また、https.nonProxyHosts プロパティを使用すると、プロキシ経由で接続する必要がないホストを指定できます。

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

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

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

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

https://support.apple.com/en-us/HT202491 も参照してください。

インストール

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

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

PARASOFT_SUPPORT_NET_INTERFACES 環境変数を作成します。
変数に安定した 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] という接頭辞が付きます。

Mac OS で jtestcli および JRE の検疫を解除して実行を許可する方法

Mac OS を使用している場合、Jtest の実行で問題が起こる可能性があります。Jtest が Mac OS の典型的なアプリケーションフォーマットではなく、App Store の外でダウンロードされているために、jtestcli およびこれに含まれる JRE が検疫で隔離されます。

これは、App Store を通さないすべてのアプリケーションに共通する問題です。Mac OS の [プライバシーとセキュリティ] システム設定を開いて個々の実行ファイルを手動で許可できます (https://support.apple.com/ja-jp/HT202491 を参照)。jtestcli および JRE から簡単に検疫属性を削除するには、jtest_installation_folder/bin/remove_quarantine_flag.sh スクリプトを実行します。

テストおよび解析

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 引数を変更している場合、上書きを防ぐために、(+=) で他の引数に追加されていることを確認してください。

jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'ALL-MODULE-PATH',
'--add-reads', "$moduleName=junit",
'--patch-module', "$moduleName=" + files(sourceSets.test.java.outputDir).asPath

]

jvmArgs += [
'--module-path', classpath.asPath,
'--add-modules', 'ALL-MODULE-PATH',
'--add-reads', "$moduleName=junit",
'--patch-module', "$moduleName=" + files(sourceSets.test.java.outputDir).asPath

]

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 レポートで一部の文字が正しく表示されない場合

Parasoft 製品によって生成されたレポートを使用するには、環境に sans-serif フォントがある必要があります。国別文字などの一部の文字がレポートで正しく表示されない場合は、システムに sans-serif フォントがインストールされていることを確認してください。

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%

Page tree

FAQs and Troubleshooting

全般

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

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

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

インストール

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

Mac OS で jtestcli および JRE の検疫を解除して実行を許可する方法

テストおよび解析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

レポート

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

IDE での操作

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

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

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

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

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

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

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

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