The name does not reflect what the variable actually holds, namely if there is at least one method annotated with @Test. I suggest hasTestableMethod.

I see an additional case here: it could be the case that the CUT does not have @Test methods but provides fixture methods, e.g., annotated with @BeforeEach and is only used as a base class for the actual test classes. I have done this before to group shared logic of multiple tests and I have also seen that elsewhere. In that case, the CUT neither is a testable class, IMHO.

An example could be (minimised to basically nonsense but it show the structure hopefully):

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

class Base {
    protected Object foo;

    @BeforeEach
    void setUp() {
        foo = new Object();
    }
}

class FirstTest extends Base {
    @Test
    void test() {
      assert foo != null;
    }
}

class SecondTest extends Base {
  @Test
    void test() {
    assert foo.equals(foo);
  }
}

From what I see, there is not reliable way to detect whether a file is part of the testing tree or not. Even searching the file path for something like test is just an heuristics, think of it for integration tests, for example.

The most reliable heuristics I can think of in the moment would be that we check for specific imports. A file importing something from org.junit.jupiter.api would be a candidate for something test-related, because that is the JUnit 5 APIs for writing tests. JUnit 4 makes it much harder because everything lives under org.junit, however, for example for implementations that use the runner APIs, we probably want to be able to generate tests. Other candidates could be com.google.guava or org.hamcrest but this list will probably never be complete.

What do you think?

Similar to my annotation in JavaPsiClassWrapper I assume that similar stuff is possible in Kotlin, too, so there might be more cases here.