By "more object-oriented", I mean, it appears to me testing frameworks like TestNG and JUnit could encourage testers to write implementations of Test and TestSuite interfaces. The current approach using @Testannotations often leads to huge classes with lots of methods and lots of boilerplate code.

A more "OO" way could, for example, look like this:

public class MyTestSuite extends framework.AbstractTestSuite {

  @Override
  public void setup() {
    //...
  }

  @Override
  public void execution() {
    executeInParallel(
      new MyTestA("some param"), 
      new MyTestA("some other param"),
      new MyTestB());
    execute(new MyTestBSubclass());
  }

  @Override
  public void teardown() {
    //...
  }
}

Are there problems with this approach I'm not anticipating?

By "more object-oriented", I mean, it appears to me testing frameworks like TestNG and JUnit could encourage testers to write implementations of Test and TestSuite interfaces. The current approach using @Testannotations often leads to huge classes with lots of methods and lots of boilerplate code.

A more "OO" way could, for example, look like this:

public class MyTestSuite extends framework.AbstractTestSuite {

  @Override
  public void setup() {
    //...
  }

  @Override
  public void execution() {
    executeInParallel(
      new MyTestA("some param"), 
      new MyTestA("some other param"),
      new MyTestB());
    execute(new MyTestBSubclass());
  }

  @Override
  public void teardown() {
    //...
  }
}

Are there problems with this approach I'm not anticipating?

Edit: My assumption here is that the framework.Test interface would have a single test method, i.e.

interface Test {
  void exec();
}

with the understanding that a Test fails if and only if an exception is thrown (alternatively, the method could return a boolean).

The thing that feels a bit funny to me about JUnit/TestNG is that the methods seem to be treated as nouns rather than verbs. If we use instances as tests, I would think we'd be able to take advantage of things like constructor parameterization, subclassing, and composition, and these would more than make up for creating a class for each sort of test. And with lambdas, we could probably get by without creating those, a lot of the time.

But there may be disadvantages I'm not thinking of...

It seems like testing frameworks like TestNG and JUnit should encourage testers to write implementations of Test and TestSuite interfaces, rather than create giant classes with lots of methods annotated with @Test. For example, something like:

public class MyTestSuite extends framework.AbstractTestSuite {

  @Override
  public void setup() {
    //...
  }

  @Override
  public void execution() {
    executeInParallel(
      new MyTestA("some param"), 
      new MyTestA("some other param"),
      new MyTestB());
    execute(new MyTestBSubclass());
  }

  @Override
  public void teardown() {
    //...
  }
}

Is this just me? Are there problems with this approach I'm not anticipating?

By "more object-oriented", I mean, it appears to me testing frameworks like TestNG and JUnit could encourage testers to write implementations of Test and TestSuite interfaces. The current approach using @Testannotations often leads to huge classes with lots of methods and lots of boilerplate code.

A more "OO" way could, for example, look like this:

public class MyTestSuite extends framework.AbstractTestSuite {

  @Override
  public void setup() {
    //...
  }

  @Override
  public void execution() {
    executeInParallel(
      new MyTestA("some param"), 
      new MyTestA("some other param"),
      new MyTestB());
    execute(new MyTestBSubclass());
  }

  @Override
  public void teardown() {
    //...
  }
}

Are there problems with this approach I'm not anticipating?