Fields annotated with @Rule should be checked to be non-static

[marcphilipp]

Currently (in 4.10) fields annotated with @ClassRule are checked to be static (like methods annotated with @BeforeClass/@AfterClass).

Fields annotated with @Rule are not checked to be non-static. However, methods annotated with @Before/@After are checked to be non-static.

IMHO this is inconsistent. I don't see any reason why one would allow static fields with @Rule annotation. If you agree, I would be glad to supply a patch via pull request.

[dsaff]

Actually, this was somewhat on purpose. For example, imagine that you wanted to take a screenshot of failing tests. You could:

public class Screenshot {
  public static TestRule takeScreenshots = Screenshots.storeFailuresIn("/tmp/some/folder");
}

public class TestA {
  public static @Rule takeScreenshots = Screenshot.takeScreenshots;
}

public class TestB {
  public static @Rule takeScreenshots = Screenshot.takeScreenshots;
}

[marcphilipp]

Why do the fields have to be static then?

public class Screenshot {
  public static TestRule takeScreenshots = Screenshots.storeFailuresIn("/tmp/some/folder");
}

public class TestA {
  @Rule public TestRule takeScreenshots = Screenshot.takeScreenshots;
}

public class TestB {
  @Rule public TestRule takeScreenshots = Screenshot.takeScreenshots;
}

Wouldn't this work as well?

[dsaff]

Good point. And the Before/After point is well taken.

OK, reopening--sounds good to me.

[stefanbirkner]

Why should we add a restriction, which is not necessary?

[marcphilipp]

Is any of the other restrictions mentioned above necessary?

[dsaff]

Well, yes. A @ClassRule has to be static, because it has to exist before any class instances have been created.

To me, the question is whether the number of legitimate uses of a static @rule would be more than the number of mistaken uses of a static @rule. Marc had largely convinced me that static @rules were more dangerous than useful. Stefan, do you disagree?

[stefanbirkner]

Are static @rule really dangerous? I don't want to add a restriction, that we don't need.

[marcphilipp]

I think they might get easily confused with class rules. Are static @before methods dangerous?

[dsaff]

Stefan,

If someone says "@rule static...", there's three possibilities:

1. There's no semantic difference between this and leaving off the static.
2. There is a semantic difference, and it's one the user intended.
3. There is a semantic difference, and it's unintended.

I can imagine situations where #3 would happen, especially where the user meant @ClassRule, and misunderstood or mistyped. Can you imagine situations where #2 holds?

[stefanbirkner]

I can imagine rules, which where item 2 holds, but this rules have a bad design and you can easily avoid them. Therefore I give up defending static @rule :-)