Re: Externally activated (global) rules

Hi Kevin!
Thank you very much for your feedback! First some words to the environment:

In the project I need the feature we currently have 9 developers and it
might be more. Even freelancers. There are something around 20k tests. What
we want to achieve is to enable a global timeout rule that applies
different timeouts to tests depending on their category (eg SlowTests.class
may take longer than other tests). Also there are other things to take into
consideration (eg is some context already loaded, otherwise the timeout
will be increased).
This rule already exists and is registered in some abstract base class. Its
working fine.
Having this amount of tests makes it very hard to make sure that every
class is annotated with it. Also not all tests inherit from the abstract
test class and I would like to keep it that way. It would be just some work
to put the rule in every test but what about tests written in the future.
I need to make sure that the rule is applied to every test especially when
the developer forgets about it. Its a rule that is intended to avoid
developers slowing down jenkins build by writing slow tests without
annotating them as such.

That said using a different runner is not an option. Also we already have a
hard time mixing spring-runner, mockito-runner, junitparam-runner (btw
we/you should copy some of that behaviour as it is a lot more flexible than
junit parameterized test [1])) aso-behaviour (btw: we/you need to think
about the runner-concept. it would be a lot better to have one runner and
registering behaviour to it (eg being able to register as many "runners" as
I want to).

Scanning classpath is a good thing. We already use classpathsuite [2]. That
enables us to create suites without having to specify all classes in it
(another feature that would very well fit junit). We could for example
annotate a rule with a classifier (basepacke, package or package.classname)
and it would get applied to everything that matches. But this kind of
behaviour would introduce a completely new way of configuration to junit (a
little cdi/spring-ish). Maybe it would be a good idea to overthink the
junit-concept leading this direction anyway but I get the feeling its a
little too much for this concern.

At last I do not think the external switch is a problem as its highly
optional. If you use it, you know what you are doing. Dont you think so?

[1] https://code.google.com/p/junitparams/
[2] http://johanneslink.net/projects/cpsuite.jsp


2013/4/29 Kevin Cooney <[email protected]>

> Henning,
>
> Sorry for the lack of response. JUnit is maintained by volunteers, and
> sometimes our day jobs get busy. I was waiting for David to respond (I am a
> sometimes contributor) but here are my thoughts.
>
> This is an interesting idea. Note that you could get what you want with a
> custom runner.
>
> My concern with adding Rules via system properties that someone running the
> tests in their IDE would see different results compared to the test runs
> from Maven. Sure, you could tell your IDE to run the tests with the same
> system properties, but it would be unexpected for most people to have to
> take a special step to make the tests run the same way as they did in the
> continuous build.
>
> Could you find some way to define the global rules via code? Perhaps you
> could add a DynamicRule to all of your tests that could apply the addition
> rules. Alternatively, you could have a class in the same package as the
> tests that defined the global rules for tests in that package (though I'm
> not sure there is a platform-independent way to scan all of the classes in
> a package that works for all runtime/deployment environments)
>
> -- Kevin
>
>
> On Mon, Apr 29, 2013 at 7:09 AM, Henning Groß <[email protected]
> >wrote:
>
> > **
> >
> >
> > Hi!
> > I have a use-case where I need to enable rules based on external
> > parameters. Therefore I cannot activate them in code. I have submitted a
> > pull request:
> >
> > https://github.com/junit-team/junit/pull/668/files
> >
> > There are some little things to fix but its an easy and functional
> > extension. Anyone mind to fix the code to a state that will get merged? I
> > did not get any feedback until now. Whole team in holidays?
> >
> > Also I am wondering when 4.12 will be released. Any plans?
> >
> > Regards and thank you!
> > Henning.
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/