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...