Declare rules on Suites, allow Propagation

[brolund]

Rules is a nice mechanism for composing rather than inheriting functionality.

This concept could be extended to suites as well, like the @BeforeClass/@afterclass annotation on a suite.

Also, by being able to declare suite rules, test case rules and test rules on a parent suite level and then propagate them down in the test hierarchy, further DRYness can be achieved.

I have made a test implementation for this, available at
http://github.com/brolund/junit

This issue is related to issue 29

[aisrael]

While we're at it, how about for the up and coming Categories? I can see having code that should run before and after all tests belonging to a specific Category, or before/after a single test that belongs to that Category.

[brolund]

To run a rule before and after each single Category test (or before/after a test with any kind of annotation) wouldn't be a problem. Just make a rule that matches annotations. A base class for this could easily be provided by the JUnit framework.

To make a rule that runs before the first test of many in a category wouldn't be a problem either. Just make a rule that looks for Category and then runs once before the first test it finds.

To run a rule after all the tests of a specific category can be more tricky depending on the requirements. It could be solved by having e.g. the same rule instance that ran before the tests run at the very end iff there were any categories in the suite.

To make a rule run after the last test in a category, but before the next test, that would require some more thought, though. One way would be to allow a visitor to traverse the test structure after it has been read, but before it has been executed, and allow that visitor to add befores/afters in the execution tree.

Or there is a better solution that I totally missed...

[brolund]

I should say that this requires the Propagate feature, which allows you to declare test/test class/suite rules on any upper level, and that then propagates the rules to the sub suites and its test cases and tests.

[vbergmann]

Has anything happened about Rule propagation in the last 7 months?

I would love to use this feature for my ContiPerf library, which provides JUnitPerf-like features on an annotation base. I would like to be able to let the user wrap ContiPerf-agnostic JUnit tests with a test suite that acts as a 'Decorator' and adds special invocation behaviour to each test method, ideally independently of the called classes' own Runner.

After recognizing that there is no way to propagate a Rule in a suite, I wrote a custom Runner using @RunWith, which works fine when applied as the only Runner. But when nesting Runners, it fails. An example is a test class which uses the Parameterized runner and you wrap it with a test suite with a custom runner: JUnit's AllDefaultPossibilitiesBuilder does not know the custom runner and with any further runnerForClass() invocation it is lost.

I think the best solution would be if the JUnit framework supported propagation of Rules over suites or, better, any nested RunnerBuilder invocation.

What is your opinon on this? Did I miss some other concept that could help me out? What are your current plans on Rule propagation support?

[dsaff]

I'm sorry this request has lingered. Is there anyone still on the thread still interested in helping to design a solution?

[panchenko]

It would be nice to have something like @ClassRule, which wraps the whole suite.

[dsaff]

@panchenko, that already exists. It's called @ClassRule. :-) Or do I misunderstand?

[panchenko]

@dsaff You are right, I missed it as my Eclipse was shipped with junit 4.8, time to upgrade :-)

[ekovacs]

@vbergmann would the @ClassRule solve the problem you were facing?

[kcooney]

@ekovacs the central request appears to be having rules on a Suite propagate to the children.

We don't have plans to do propagation, and I don't know how that would be implemented.

Also we generally avoid features where you get different behavior in a test depending on how it was run. IDEs and even some build tools let you run individual test cases or methods. When running a test in isolation, how does it know that it should inherit behavior from a parent suite?

Perhaps the JUnit 5 test engine abstraction is a better solution for some of the larger problems mentioned in the comments on this Issue.