Thanks for looking into this so promptly!
In the Spring Framework build, we do in fact set ‘scanForTestClasses’ to ‘false’. Thus, adding an exclusion for ‘’**/$’’ at the all-projects level serves as a viable workaround. Thanks for the tip.
Note, however, that this problem only arises when we use ‘-Dtest.single’. So in that sense, it is specific to the case where ‘-Dtest.single’ is used, at least in combination with the filters we have in place. I have not looked at the implementation in Gradle, but it would appear that the include generated for ‘-Dtest.single’ overrides any other include filters such as ‘"/*Tests.class"’ and '"/Test.class"’. As you can see from my comments above, without the explicit exclusion for ‘’**/$*’’, Gradle attempts to execute ‘WebSocketConfigurationTests$1’ as a test class.
In summary, although ‘’**/$’’ serves as viable work-around for us, I still feel that Gradle should ensure that the asterisk before ‘.class’ is non-greedy when generating the full pattern for ‘-Dtest.single’. I say non-greedy in the sense of regular expressions: the wildcard after the pattern should only match against a top-level class name; it should not eat “$*” before “.class”.
In the very least, Gradle should not pass any class references to the JUnit or TestNG test runners for classes that are not test classes (e.g., abstract classes, annotation types, concrete classes without ‘@Test’ annotations, etc.), regardless of the value of ‘scanForTestClasses’. Otherwise, builds will unavoidably break.