Global rules

[brolund]

"Global rules" are rules that are declared in one place and applied to all test cases/tests/suites in a test run.

"One place" could be a properties file, named by convention, e.g. "/global-junit-rules.properties", or they could be declared in a test suite and propagated (see http://github.com/KentBeck/junit/issues#issue/40), or in some other way.

From forum thread
http://tech.groups.yahoo.com/group/junit/message/22133

[ghost]

I propose to name the file "junit.properties". In the first release only the global rules would be configured here, but then, as the need might come, we can add more parameters, such as:

• which tests to execute/exclude/ignore
• test suites to run/exclude
• categories to run/exclude

The junit.properties file should be located somewhere in the classpath. If it is found, it is loaded and used. Otherwise JUnit runs just like before.

[johlrogge]

I prefer the properties solution over running from a specific suite. The reason is that I want my tests to behave the same wether I run them via a suite or not to the highest extent possible. I agree with http://github.com/KentBeck/junit/issues/#issue/69/comment/92832 on the name of the poperties file. It would be familiar for log4j users which are many.

[dsaff]

Haven't forgotten this. :-)

One challenge is that I prefer all the information relevant to understanding how a test executed to be available by starting with the source code of the test.

If you had to "opt in" to the global rules, using a two-word annotation like:

@Rules({Global.class})
public class MyTest

Would that dampen the usefulness of this feature?

[brolund]

I had. ;-)

Your proposal is more instantly readable, but also more tedious (adding annotations everywhere), more error prone (given we really want something applied on all tests), and more obtrusive (changing all files).

If I recall correctly, I particularly wanted a way to add behavior to a test run in an unobtrusive way. This contradicts having all information in the test source. I guess which way to go will be a call of judgement on the values. :-)

[dsaff]

So the original forum thread above doesn't want a Rule, they want a RunListener. Since listeners don't impact the running of a test, I'd be fine with a general way to read listeners from a property file.

But that would be a different thing than globally adding a Rule, which could go so far as causing every test with a name starting with "g" to fail, with few clues why to the poor test maintainer.

So is this about listeners, or rules? :-)

[brolund]

Hehe, good question. I think I wanted a listener that provided me with all the events from test execution, including a reference to the test/suite class at hand (would have allowed some manipulation like injection), and data in theories.
Rules where the closest to that desire at the time, but I think it never quite got there.

I did find the RunListeners and related classes to be a bit tricky to use for extension, forcing me to do a bit too much digging into and understanding of the internals of JUnit.

Although I don't use as much JUnit today as I used to, I still think a solid and exhaustive listening framework on top of the core would be the way to go. :-)

[dsaff]

@brolund, Are you interested enough to open a rephrased feature request?

[brolund]

Sure. I'll basically copy'n'paste my last post into a new feature request.

[brolund]

https://github.com/KentBeck/junit/issues/444

[dsaff]

Sounds good. Continuing there.