Refactoring Suite, Parameterized and class runners to allow reuse in custom Runners

[PeterWippermann]

As discussed in #1338 I refactored some of runners to be able to reuse their functionality. This mainly included the conversion of private instance methods to public (static) class methods. When functionality was hidden in other methods I also introduced new methods (e.g. Parameterized.normalizeParameter(Object)).

[kcooney]

Could you please remove all the unnecessary reformatting? It makes it hard to review.

On first glance, the methods being added to BlockJUnit4TestRunner and Suite are so small that the cost of you copying the code is much smaller than the cost of us maintaining the new API.

allParameters() could be a new non-static method in TestClass

I don't understand why you need the changes to ParentRunner. Wouldn't your new runner extend ParentRunner?

[PeterWippermann]

@kcooney How should I remove the formatting? Sorry, but Eclipse always formats the whole file and it's not my fault that this file wasn't formatted accordingly before :-/

[kcooney]

Tell Eclipse to not format files on save (or, if possible to only reformat changes lines). I realize the files might not follow the current formater settings, but reviewing code that is reformatted in the same pull is painful

[PeterWippermann]

Maybe we should have another PR to format all files under org.junit.* once and for good?

[PeterWippermann]

Regarding your feedback, @kcooney :

• I'd like to reuse functionality which easily finds and processes annotations for me. For that cause BlockJUnit4ClassRunner.getTestRules(Object, TestClass) and Suite.getSuiteClasses(Class<?>) are very handy. I would like to reuse them without copying them. As @SuiteClasses and @TestRule are tightly related to these classes, I think such methods should be available there.
• Parameterized.allParameters(TestClass) uses other private methods of Parameterized. It's especially depending on @Parameters, which is nested in Parameterized. So shouldn't this "annotation-processing" method also be there?
• Regarding ParentRunner: Yes, you're right. Those methods could be protected instance methods as well. Would work for me, because my ParameterizedSuite extends ParentRunner indeed. However, do you want to force a user to extend that class to be able to access this functionality?

Would it appeal more to you, if I move all those annotation-related methods to a single (or multiple?) helper class? Its constructor could be initialised with an instance of TestClass. So you instantiate this annotation helper once and have unified access to the annotations then. How should we name it?

[kcooney]

I personally prefer that we don't do a pass of reformatting all the files, because it creates conflicts for anyone with an open pull. Perhaps @marcphilipp feels differently. In any case, I'll try to continue the discussion, but it would be much easier without so many extraneous diffs.

Addressing your bullets in order:

• The amount of reuse is small, and having public static methods to share it (in these classes or other classes) is a bit ugly. Perhaps there is a natural set of classes to extract. In any case, some of these proposed methods have very little code, so the benefit of making it sharable should be weighted against the cost (API we must support, difficulty when we want to make functional changes to the classes, etc)
• Perhaps we can make a subclass of TestClass named ParameterizedTestClass. Hanging functionality as methods on an object with data is better than a bunch of methods
• ParentRunner is designed to be subclassed, and developers are encouraged to subclass it for runners that have a parent-child relationship.

[kcooney]

Curious why you want to call these directly vs. calling classBlock(). If you cannot use classBlock() then perhaps instead of making these three protected we should extract one protected method that calls all three so 1) your runner isn't hard-coding the order and 2) we can add more calls in the future (ex withClassFixtures()). Perhaps call the new method withClassStatements()

[PeterWippermann]

I like your proposal to introduce withClassStatements(). I also had something like this in mind before, but didn't brought it to an end. I will incorporate it now.

I'd like to propose to leave withBeforeClasses(...) (and the others) protected anyway. But the documentation should encourage to use withClassStatements().

I can't call ParentRunner.classBlock(...) in my custom Runner because between invoking the children and applying the class statements, I'd like to apply @TestRules. ParentRunner doesn't support these.

        Statement statement = childrenInvoker(notifier);

        List<TestRule> testRules = BlockJUnit4ClassRunner.getTestRules(testInstance, getTestClass());
        statement = BlockJUnit4ClassRunner.withTestRules(testRules, getDescription(), statement);

        statement = withClassStatements(statement);
        return statement;

[kcooney]

@PeterWippermann I don't understand what you mean by "I can't call ParentRunner.classBlock(...) in my custom Runner because between invoking the children and applying the class statements, I'd like to apply @testrules". The method withClassRules() applies all of the rules annotated with @ClassRule. You shouldn't invoke rules annotated with TestRule in ParentRunner because there is no instance of the class.

[PeterWippermann]

@kcooney Please have a look on my updates :-)

[kcooney]

I'm sorry, but if you want me to spend more time on this you will need to remove all the extraneous reformatting

[PeterWippermann]

Which files are you complaining about, @kcooney ?

• BlockJUnit4ClassRunner is indeed a victim of formatting the whole file
• the "@@ -1,130 +1,130 @@ diff" of Suite is a bug of Github's display, IMO. Same for BlockJUnit4ClassRunnerWithParameters. I don't see any format differences there.

I really recommend to format your code base once to meet your own code style.

[PeterWippermann]

I reported #1350 to get the code style right. Afterwards comparing the code should be easy again.

[kcooney]

The problem with Suite is likely due to the line end changes. Perhaps your editor is changing the line endings. You can easily fix it in Emacs; see https://www.emacswiki.org/emacs/EndOfLineTips

We've done passes in the past to reformat the code; it doesn't stick. It also causes merge conflicts for pending pulls.

In any case, all the maintainers work on JUnit in our free time, so we have limited time to review pulls. Having a significant amount of reformatting that is unrelated to your functional changes makes it take longer to review the diffs.

[PeterWippermann]

You were right!
I reformatted Suite and BloackJUnit4RunnerWithParameters with Unix line endings and UTF-8 as explained here. The extraneous diffs are gone now.

Still, I'm wondering why not all the files I touched got polluted like this.
The coding style guide should contain an advice for these settings as well.

[PeterWippermann]

@kcooney Could you have another look on this please?

[kcooney]

@PeterWippermann I am sorry, but my new job has kept me quite busy.

There are still a lot of extraneous diffs in this pull. That makes it take longer for me to re-review it when you ping the thread, and like all of the maintainers, I work on JUnit in my free time (which is very limited currently).

[PeterWippermann]

Waiting for #1350

[PeterWippermann]

For the period before this PR can be merged, I set up a project that provides exactly this functionality and makes it available for reuse: https://github.com/PeterWippermann/parameterized-suite