missing current instance in TestRule apply()

[RainerW]

I switched form 4.8 to 4.10 and decided to change my MethodRule's to TestRule ... bad idea.

I'm missing a way to get the FrameworkMethod, and the current test instance, they are missing now in the apply method:

old:
public Statement apply(final Statement base, final FrameworkMethod method, Object target)

new:
public Statement apply(final Statement base, final Description description)

How can i get them? I debugged and the actual Statement instance is of type InvokeMethod, this would have what i need, but dosn't have getter for the private fields.

So, at the moment i can just keep using MethodRule, but i'm afraid this will not work in further versions anymore.

[chbaranowski]

+1

would be nice to have ?

• a getTarget() method in the Statement class, returns null if class rule
• a getTargetClass() method in the Statement class
• a getFrameworkMethod() method in the Statement class, return null if class rule

[dsaff]

You can pass the class instance into the TestRule at creation time:

@rule public TestRule myRule = new MyRule(this);

[chbaranowski]

Ok not nice, but what is about the test method?
If you like to process custom annotations by a JUnit rule. How can we implement this with the new rule interface?

Here an example:

…
@rule public SetupDatabaseRule setupDatabaseRule = new SetupDatabaseRule ();
…

@testdataset(DemoDataSet.class) // custom annotations
@test public void testSample(){...}

[dsaff]

Christian,

The annotations are available at Description#getAnnotations

[chbaranowski]

ok thanks a lot
With Description#getAnnotations and new MyRule(this); we should be able to move our rules to the the new interface

[RainerW]

• passing this into a rule is ugly, but i could live with that
• Not having the actual method instance could be a problem with multiple overloadings
• I could find annotations on parent class/hierarchy also via this

So thanks, i now know how to get the stuff i need. Sadly this has effects on the rules themself, so i need to actually change the rules, not only the base class.

Still i would recommend to at least pass $this in some way.

[RainerW]

While rewriting i found that the description.getAnnotations() only finds Annotations from the current testMethod, but none from overwritten methods. This is actually a feature i need.

https://gist.github.com/1309806

So description.getAnnotations() should use AnnotationUtils.findAnnotation()

[RainerW]

Actually, passing in $this, is really ugly. This breaks all existing projects, not only the rules. I have actually to change all projects and bloat up the constructor.

Isn't there any other way to get $this?

[dsaff]

RainerW,

I can understand the frustration. I can imagine some change to the way we handle TestRule would be useful. Can you share a little more about what your current MethodRule does? Thanks,

David

[hprange]

Hi David,

I feel the same frustration described by others. I've developed a JUnit extension that strongly relies on MethodRule. The rules of my framework can interact with the target object to create/initialize objects for annotated fields. Here is a simple example:

@Rule MyRule rule = new MyRule("parameter1");

@Dummy MyObject dummy; 

MyRule detects the presence of the @Dummy annotation, creates an instance of MyObject and sets it on the dummy field of the target object.

Passing 'this' as a parameter to MyRule isn't a solution because it moves the complexity to solve the problem to users of my framework, which is really undesirable. The lack of a reference to the target object has become a flaw in JUnit framework, and I'm sure the problem can be solved within JUnit internal logic.

[dsaff]

Henrique, others,

If we simply undeprecate MethodRule, does this problem go away? Thanks,

David

[RainerW]

This would solve the problem, but now you have two interfaces doing the same thing. So one is just cluttering your API. Which one should you use for new rules?

I would strongly recommend to get rid of one of the interfaces and pass in a clean RuleDetails:

interface RuleDetails {
Descriptor getDescriptor(); // new features from TestRule
Object getTarget(); // target instance of null for Classrules
FrameworkMethod getTestMethod(); // get Test Method ( needed for reflections )
}

Or get rid of both end clean your api for the next release.

[hprange]

Hi David,

I think it is a good solution. Fix the problem and keep compatibility with older versions of JUnit. Thanks for your feedback.

Hi Rainer,

Each interface could have a meaning. Static fields annotated with @ClassRule should be a subtype of TestRule. Non static fields annotated with @Rule should be of type MethodRule. If a rule can be used as a @ClassRule and @Rule, it can implement both. This solution also avoids the misuse of TestRule as a MethodRule and vice-versa.

[RainerW]

I completely agree, having a distinct interface for @ClassRule and @rule is a good thing.

But still you have to explain why in MethodRule you have no Descriptor parameter (Not that i can currently think of a usecase for that parameter ) ?

[hwilming]

Hello,

I’m really vote for the MethodRule interface, because it is a very good point to extend JUnit based Tests with custom functionality. To do something with the test instance, is in my opinion a common use case.

I think the removal of the interface will break a lot of JUnit based Frameworks and APIs. For example our API needs the test instance to initialize some fields of the object under test. This is an Open Source API that is already used in many projects.

I'm already looking for alternatives, but there is no elegant way to get access to the test instance. To passing this into a rule is very ugly and using inheritance instead of Rules is a step back in the wrong way.

I would be very happy, if you undeprecate the MethodRule.

Thanks a lot!
Heinz