Testng: スーパークラスの@Testメソッドは、サブクラスごとに再実行されます

@ vlad230

PSgithubの問題でコードを編集するのは非常に悪いです...別の場所に移動してください。

Markdownに慣れるために時間を費やしたいと思うかもしれません。 これにより、フォーマットとともにコードスニペットを非常に簡単に追加できます。

ここであなたの問題を理解しているのかよくわかりません。 最終的に、子クラスは基本クラスのメソッドも取得します。 また、TestNGアノテーションが付けられている場合は、すべての子クラスに対して実行されます。 これがTestNGの動作です。 つまり、TestNGは設計どおりに機能していると言えます。

@ juherr-あなたの考えは？

@krmahadevanフォーマットしてくれてありがとう:)

ここであなたの問題を理解しているのかよくわかりません。 最終的に、子クラスは基本クラスのメソッドも取得します。 また、TestNGアノテーションが付けられている場合は、すべての子クラスに対して実行されます。 これがTestNGの動作です。 つまり、TestNGは設計どおりに機能していると言えます。

私に言わせれば、スーパークラスでテストを複数回実行しても意味がありません。
これが現在のTestNGの予想される動作である場合は、改善のためにこれを追加できます。

設計どおりに機能します。
baseMethodテストを独自のクラスに移動してみませんか？

@ vlad230

私に言わせれば、スーパークラスでテストを複数回実行しても意味がありません。

正確に何を達成しようとしていますか？ シナリオを詳しく説明したり、説明したりしていただければ幸いです。

これが現在のTestNGの予想される動作である場合は、改善のためにこれを追加できます。

そのカウンターが直感的であるため、それが拡張機能として取り上げられるかどうかはわかりません。 基本的に、子クラスがいくつ存在していても、基本クラスのメソッドを1回だけ実行する場合は、次のようにして、テストプロジェクトで今日実行できます。

1. 基本クラスにorg.testng.IHookable実装してもらいます
2. そのrun()メソッド内に、基本クラスのメソッドがすでに実行されているかどうかをチェックし、実行されていない場合は実行する編集チェックを追加します。

これがサンプルです

基本クラスのメソッドを1回だけ実行する必要があることを示すマーカーインターフェイス

import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({METHOD, TYPE})
public <strong i="20">@interface</strong> RunOnce {
}

これがステートトラッカーシングルトンです

import java.lang.reflect.Method;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class StateTracker {

  private static final StateTracker instance = new StateTracker();

  private final Map<String, Object> runOnceData = new ConcurrentHashMap<>();

  private StateTracker() {}

  public static StateTracker getInstance() {
    return instance;
  }

  boolean canExecute(Method method) {
    RunOnce runOnce = method.getAnnotation(RunOnce.class);
    String methodName = method.getName();
    boolean execute = true;
    if (runOnce != null) {
      if (runOnceData.containsKey(methodName)) {
        execute = false;
      } else {
        runOnceData.put(methodName, new Object());
      }
    }
    return execute;
  }
}

基本クラスは次のようになります

import org.testng.IHookCallBack;
import org.testng.IHookable;
import org.testng.ITestResult;
import org.testng.annotations.Test;

public class BaseTest implements IHookable {

  <strong i="27">@Test</strong>
  <strong i="28">@RunOnce</strong>
  public void baseclassTestMethod() {
    System.err.println("Base class test method executed");
  }

  <strong i="29">@Override</strong>
  public void run(IHookCallBack callBack, ITestResult testResult) {
    boolean execute =
        StateTracker.getInstance()
            .canExecute(testResult.getMethod().getConstructorOrMethod().getMethod());
    if (execute) {
      callBack.runTestMethod(testResult);
    } else {
      testResult.setStatus(ITestResult.SKIP);
      testResult.setThrowable(new RuntimeException("Intentionally skipping"));
    }
  }
}

子クラスは次のようになります

import org.testng.annotations.Test;

public class ChildClass1 extends BaseTest {

  <strong i="33">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

import org.testng.annotations.Test;

public class ChildClass2 extends BaseTest {

  <strong i="36">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

テスト結果を整理し、 @RunOnceを使用して注釈が付けられたスキップされたテストを削除するフィルタリングメカニズムを追加する必要があります。

@krmahadevan
正確に何を達成しようとしていますか？ シナリオを詳しく説明したり、説明したりしていただければ幸いです。

テストを複数のクラス（機能に関連する）に分けようとしています。 たとえば、「子クラス」のテストと一緒に基本クラスからのテストをサポートする他のヘルパーメソッド（テストではない）と一緒に@Beforeおよび@Afterメソッドを使用して、その機能のセットアップ部分を持つ「基本クラス」があります。 "。 したがって、この方法では、子クラスに新しいテストを追加するだけで、子クラスのコードを複製することはありません。
基本クラスには、その機能のより一般的な部分をテストするいくつかのテストメソッドがあり、子クラスには、より具体的なテストがあります。
クラスを並行して実行することでテストの実行時間を最適化しようとしているため、50以上のテストメソッドを持つ元の「基本クラス」を複数の小さな「子クラス」に分割して、これらの小さなクラスが他のスレッドに分散されるようにする必要がありました。 / executors。

@krmahadevanは詳細な解決策に感謝しますが、私には少し面倒に見えます。 TestNGはカスタマイズできるので、これをデフォルトの動作と見なしたいと思います。
基本クラスからテストを絶えず再実行する必要はないと思います。 セットアップ/ティアダウンの問題である場合は、いつでも@ Before / @Afterを使用できます。これは、基本クラスの子クラスの前に毎回再実行されます。

はい、動作は構成可能だと思います。

実際、子インスタンスごとに親テストを実行するユースケースは見つかりません。
統合テストのようにテスト状態が変更されることが多いため、テストへの直接の依存関係（ dependsOnMethods ）がない限り。

@krmahadevan WDYT？

@ vlad230

詳細な解決策に感謝しますが、私には少し面倒に見えます

あなたのユースケースも、通常とは少し異なって見えます。 さらに、私はあなたにそれがどのように行われることができるかの実際的な例を与えました。 あなたがする必要があるのは、これを採用し、これに基づいて構築することだけです。

TestNGはカスタマイズできるので、これをデフォルトの動作と見なしたいと思います。

いいえ、それは私の意見ではできません。 テストは常に実行されることを目的としています。 それらが基本クラスに存在するからといって、それらを選択的に実行する必要があるという意味ではありません。 TestNGはカスタマイズできます。 しかし、それはTestNGがすべてのカスタマイズをサポートする必要があるという意味ではありません。 ユーザーが自分のニーズに合わせてカスタマイズし、操作できるようにする方法を提供する必要があるだけです。 私が共有したサンプルは、TestNGを変更せずにこれらのカスタマイズを適用した例です。

基本クラスからテストを絶えず再実行する必要はないと思います。 セットアップ/ティアダウンの問題である場合は、常に@ Before / @afterを使用できます。これは、基本クラスの子クラスの前に毎回再実行されます。

私にとって、それは物事を見る一つの方法にすぎません。 特定のメソッドを毎回実行する必要がない場合は、 @Testアノテーションを使用しないでください。 @BeforeTest （ <test>タグごとに1回だけ実行される）や@BeforeSuite （ <suite>ごとに1回だけ実行される）などの構成アノテーションを非常にうまく使用できます。

基本クラスのテストメソッドが本当にテストメソッドであるかどうかはわかりません。 私には、テストを実行するために満たすセットアップ条件を確立する構成のように聞こえます。

@ juherr-ここでのユースケースに同意するかどうかはよく@Testアノテーションではなく、構成アノテーションを使用する必要があります。

実装側では、特に人々が実行の手段としてグループを使用し始めるときに、これはコードベースに多くの混乱を追加すると思います。

さらに、現在TestNG（例として共有しています）内でこれを行う方法がすでにあると感じています。 なぜそれを活用しないのですか？ これは1回限りのユースケースのようであり、TestNGの通常の使用方法に適合していないようです。

@krmahadevan申し訳ありませんが、あなたは私がやろうとしていることを理解していなかったと思います。
親クラス（BaseTest-例：DashboardTest）には、現在15個のテストがあり、3つの子クラス（例：DashboardFilterTest、DashboardTreeTest、DashboardEditorTest）があり、それぞれにテストがあります。 私の投稿で説明したアプローチを使用すると、テストを実行するたびに、それらの15のテストが3回実行され（つまり、3x15 = 45のテストが実行されます）、価値がなくなり、実行時間が無駄に長くなります。 15回のテスト。

親クラスにあるテストが、子クラスからのテストが実行されるたびに再実行されることは、まだ意味がないと思います。 TestNGのデフォルトの動作では、拡張している子クラスの数に関係なく、親クラスからテストメソッドを1回実行することをお勧めします。

これができないのなら、私は理解しています。 とにかくありがとう。

@ vlad230

コンテキストを追加していただきありがとうございます。

親クラス（BaseTest-例：DashboardTest）には、現在15個のテストがあり、3つの子クラス（例：DashboardFilterTest、DashboardTreeTest、DashboardEditorTest）があり、それぞれにテストがあります。 私の投稿で説明したアプローチを使用すると、テストを実行するたびに、それらの15のテストが3回実行され（つまり、3x15 = 45のテストが実行されます）、価値がなくなり、実行時間が無駄に長くなります。 15回のテスト。

その場合、なぜDashboardFilterTest, DashboardTreeTest, DashboardEditorTestがDashboardTest拡張するのでしょうか。 DashboardTestテストは、ここで継承アプローチを利用するのではなく、独自のクラスに存在する必要があるようです。 基本クラスは、すべての一般的なテストメソッドを削除して別のテストクラスに格納するようにリファクタリングする必要があります。DashboardTestは、一般的な非@Testメソッドのみを格納するようにリファクタリングする必要があります。

これができないのなら、私は理解しています。 とにかくありがとう。

それらが実行できるかどうかではありませんが（実装の課題は別のトピックです）、ユースケース自体の有効性を理解しようとするのにまだ苦労しています。

@krmahadevan

その場合、なぜDashboardFilterTest, DashboardTreeTest, DashboardEditorTestがDashboardTest拡張するのでしょうか。 DashboardTestテストは、ここで継承アプローチを利用するのではなく、独自のクラスに存在する必要があるようです。 基本クラスは、すべての一般的なテストメソッドを削除して別のテストクラスに格納するようにリファクタリングする必要があります。DashboardTestは、一般的な非@Testメソッドのみを格納するようにリファクタリングする必要があります。

'DashboardTest'には、子クラスにも必要なヘルパーメソッド（openDashboard（）、createDashboard（）など）とsetup / teardown / cleanup（@ Before / @ After）メソッドが含まれています。 したがって、子クラスでコードを複製する必要はありません。
はい、「DashboardTest」の一部のテストは他の特定のクラスに移動できますが、より一般的であるため、ここに残しておきたいと思いました（たとえば、ダッシュボードの全体的な外観、基本的なCRUDテスト、またはそうでないテストをチェックするなど）。特定のカテゴリに当てはまるか、混合されています）。

確かに、@ Test以外のテストクラスを作成することはできますが（奇妙で、誰かが誤ってここにテストを追加する可能性があります）、この問題を回避するだけですよね？

@ vlad230

'DashboardTest'には、子クラスにも必要なヘルパーメソッド（openDashboard（）、createDashboard（）など）とsetup / teardown / cleanup（@ Before / @ after）メソッドが含まれています。 したがって、子クラスでコードを複製する必要はありません。

意味あり。 はい、それらは基本クラス内に非常にうまく存在できるため、構成メソッドは子クラスでも使用できるようになります。

はい、「DashboardTest」の一部のテストは他の特定のクラスに移動できますが、より一般的であるため、ここに残しておきたいと思いました（たとえば、ダッシュボードの全体的な外観、基本的なCRUDテスト、またはそうでないテストをチェックするなど）。特定のカテゴリに当てはまるか、混合されています）。

それでも、すべての汎用@Testメソッドを含むGenericDashboardTest extends DashboardTestというクラスを作成できます。

確かに、@ test以外のテストクラスを作成することはできますが（奇妙で、誰かが誤ってここにテストを追加する可能性があります）、この問題を回避するだけですよね？

まあ、それはコードレビューがそこにあるのではありません:)そのような滑りを防ぐために。 基本クラス（あなたが説明したものから）は、一般的な一般的な@Testメソッドを含む必要はありません。 ヘルパーと構成だけを収容することができ、基本クラスを拡張して一般的なテストメソッドを収容するもう1つのテストクラスを作成できます。 それは目前の混乱を解決するはずです。

_設計どおりに機能する_という解決策でこの問題を解決します