Loading ...
Sorry, an error occurred while loading the content.

Re: [junit] Re: Categories in JUnit 4.8

Expand Messages
  • David Saff
    ... Georg, We came very close to adding an ExcludeCategories annotation. However, we decided to stay at a minimal feature set for Categories in the initial
    Message 1 of 38 , Nov 21, 2009
    View Source
    • 0 Attachment
      On Fri, Nov 20, 2009 at 10:07 PM, Georg <le_garcon_enerve@...> wrote:
      > Hi David,
      >
      > Did you gave thoughs to cases where one would like to exclude certain tests? E.g.: run all  tests that are not in (a) certain category(s)? This is probably not difficult add in one way or another onto the concept of categories, but the answer to "which test is now acctually included" could become confusing in cases where a test is in an included and an excluded category. I would like to see something here that does not require a lot of browsing through hierarchies of suites nad categories. This may in my approach not well solved either as suites can extend on other suites: if a referenced suite includes a certain test, it is executed even if the extending suite excludes a test.

      Georg,

      We came very close to adding an ExcludeCategories annotation.
      However, we decided to stay at a minimal feature set for Categories in
      the initial release, figuring that if the whole API turned out to be
      wrong, or if users just shrugged, then any time put into perfecting
      the mini-language of category filter configuration would be wasted.
      If the feature takes off, I think we'll certainly revisit that
      decision (especially if a highly-voted github issue requests it, hint,
      hint.)

      However, Iyou touch on another concern: a simple category feature set
      that is easy to understand, but leaves out 20% of valid use cases, may
      be preferable to a more "feature complete" feature implementation that
      requires pages of documentation to fully grok. I don't know that
      we're in danger of either extreme yet.

      David Saff

      >
      > And more fundamentally: is the idea/need of exclusion meaningfull or just a result of badly organising tests (I'd say no, but I may be wrong)?
      >
      > Cheers,
      >  Georg
      >
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Bård Lind
      Hi David. Sorry to hear that extensions to @Test is not an option. (Not possible). Implementing @Fast and @Test will only restrict us to use only two
      Message 38 of 38 , Dec 14, 2009
      View Source
      • 0 Attachment
        Hi David.

        Sorry to hear that extensions to @Test is not an option. (Not possible).
        Implementing @Fast and @Test will only restrict us to use only two
        categories, and not all the categories
        a project needs. Our project are looking at using "With data", "Without
        data", "With environment", "Without environment", "Fast" and "Slow". (For
        example sake)

        Using @...(SlowTests.class), and
        @Category({FastTests.class}) with classes, is then a much better solution
        than using strings. Again because this supports refactoring, and prevents
        typos.


        Bård



        On Fri, Dec 11, 2009 at 4:01 PM, David Saff <david@...> wrote:

        >
        >
        > This has come up a couple times, but it has design challenges,
        > especially the need for the core JUnit runner, which should not know
        > about categories, having to recognize different annotations as meaning
        > the same this as @Test. Now, something like @Fast @Test would cause
        > much less upheaval. Would that work for you?
        >
        > David Saff
        >
        >
        > On Thu, Dec 10, 2009 at 2:51 AM, baardl <bard.lind@...<bard.lind%40gmail.com>>
        > wrote:
        > >
        > > Hi.
        > >
        > > My take on using strings as markers are that this will faile over time.
        > This
        > > due to miss-spelling of the
        > > category name, and because refactoring will be hard/impossible.
        > >
        > > Favor classes or interfaces.
        > > One wish thoug is to be able to implement exctentions to @Test, like
        > > @FastTest, @SlowTest.
        > >
        > > baardl
        > >
        > >
        > > Cédric Beust ♔ wrote:
        > >>
        > >> On Tue, Nov 17, 2009 at 1:44 PM, Kent Beck <kentb@...<kentb%40earthlink.net>>
        > wrote:
        > >>
        > >>> Malte,
        > >>>
        > >>> Thank you for the question. We went back and forth on this. The two
        > >>> positive features of using interfaces as "tags" is that the compiler
        > can
        > >>> check them and inheritance works. The need for otherwise useless
        > >>> interfaces
        > >>> is the cost of this decision.
        > >>>
        > >>> To my way of thinking, categories should be handled by the IDE--they
        > are
        > >>> meta-data that belongs with the test runner, not with the tests
        > >>> themselves.
        > >>
        > >>
        > >> There are two different aspects to categories:
        > >>
        > >> - Which tests to run depending on what category they belong to is
        > >> information that belongs in the runner.
        > >> - What categories tests belong to is information that belong in
        > tests.
        > >>
        > >> Another downside of interface categories is that you can't use regular
        > >> expressions to run a set of them. For example, in TestNG, if you
        > specify:
        > >>
        > >> @Test(groups = "database.postgresql")
        > >> ...
        > >>
        > >> @Test(groups = "database.mysql")
        > >> ...
        > >>
        > >> You can then run all the database tests by including "database.*".
        > >> However,
        > >> you can approximate this by allowing tests to belong to more than one
        > >> category (not sure if your implementation allows that).
        > >>
        > >> --
        > >> ***Cédric
        > >> *
        > >>
        > >>
        > >> [Non-text portions of this message have been removed]
        > >>
        > >>
        > >>
        > >
        > > --
        > > View this message in context:
        > http://old.nabble.com/Categories-in-JUnit-4.8-tp26395582p26723326.html
        > > Sent from the JUnit - User mailing list archive at Nabble.com.
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.