Re: should @Ignore processing and Filter processing be combined?

On Wed, Feb 27, 2013 at 11:18 AM, Noel Yap <[email protected]> wrote:

> **
>
>
> This topic started from
> https://github.com/junit-team/junit/pull/635#issuecomment-14189604.
>
> Full disclosure: I'm for combining such processing since my group uses
> Filter notification to know which tests are being skipped in CI while
> allowing such tests to be run on dev machines. Our goal is to
> eliminate such tests, but exposure of those tests is required to
> achieve this goal.
>

It sounds like you either want Categories, have your own annotation and
write a custom Filter.

Another option would be to write a method that checks an environment
variable or system property and based on the results optionally calls
Assume.assumeTrue(false).

>
> The following (especially the cons since I'm biased and there's lots
> about JUnit I don't yet understand) will likely be missing items but
> I'll try to be fair about them. If there's anything missing, I'm sure
> people will jump in.
>
> Pro's:
> * Simpler code. @Ignore processing would simply be just another
> filter. Existing duplicate code to check for @Ignore annotations will
> disappear.
> * Conceptually simpler. @Ignore and Filters aren't two separate things
> with different hard-coded nuances.
>
But they currently *do* have different nuances. Filtered tests do not show
up in the Description tree; Ignored tests do. JUnit provides notifications
when "running" an ignored test; no notification exists for filtering tests.

They are also semantically different IMHO. @Ignore is a code-level
indication to never run a test. Filtering is a way to run a subset of the
tests.

It sounds like you want tests that are run in some environments and not
others; I think Ignore is a poor choice because it doesn't allow you to
specify which environments you want to run them in. Again, I would use
Categories or a custom annotation and a filter.

>
> Con's:
> * Slower performance. Since notifications will have to be made, the
> set of tests to be run can't be culled down. Such slower performance
> is theoretical and ought to be measured.
>
> Potential alternatives:
> * Have an option (somewhere) that allows notification for filtered tests.
> * Have a fireFiltered() method for notifiers.
>

Filtering can happen before RunNotifiers are added. One way to filter is to
create a Request, and then call Request.filterWith(), and then run the
tests. When you filter a request, the filtered items vanish from the
Runner/Description tree. It would be hard to change that behavior without
breaking existing users.

-- Kevin


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