Re: Externally activated (global) rules

Hello,

Are you using maven?

If so, one option that you could possibly consider is using a different
provider to surefire.

A provider is a class which knows how to run a set of tests. There is a
provider for JUnit3, JUnit pre 4.7 and JUnit post 4.7. JUnit post 4.7 uses
the JUnitCore, which you could replace with your own version, which inserts
the same rule everywhere.

It seems (at first glance) to be a better way to get global behaviour from
your jenkins server.

Matthew Farwell.


2013/4/30 Henning Groß <[email protected]>

> **
>
>
> 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]
>
>  
>


[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/