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

Re: Making a better Suite annotation

Expand Messages
  • yme0987654321
    I m not sure what the motivation for having a separate runner would be. I suppose it could be called a DynamicSuite, or SuiteMethodRunner. I m just not sure
    Message 1 of 5 , May 1 6:05 AM
      I'm not sure what the motivation for having a separate runner would be. I suppose it could be called a DynamicSuite, or SuiteMethodRunner. I'm just not sure that it adds anything.

      Certainly from the user perspective I would see it as more intuitive to have one @RunWith(Suite.class) annotation with some variations on how to set up the suite rather than have two different runners and have to understand which one to use when.

      --- In junit@yahoogroups.com, David Saff <david@...> wrote:
      >
      > Sorry for the long delay in response.
      >
      > This is a good idea, I think. I wonder if it needs to be in the same
      > runner as Suite, or could it be a different Runner?
      >
      > David Saff
      >
      > On Wed, Feb 25, 2009 at 10:34 AM, yme0987654321 <yme0987654321@...> wrote:
      > > I have the following challenge, with a proposed solution. If there is
      > > interest, I would be happy to contribute a patch to the JUnit project
      > > to address it. On the other hand, if there is a way to solve this
      > > problem differently in JUnit already, please let me know.
      > >
      > > Ant and IDEA (the IDE from Intellij) don't agree on how to gather
      > > classes for test. IDEA inspects the actual class for things that
      > > extend TestCase or have a JUnit annotation on the class (or have a
      > > static suite method) and executes the test. Ant gathers tests via
      > > class names. To use the Ant method with JUnit outside of Ant, you can
      > > use JUnitCore, and just pass it an array of classes gathered in the
      > > Ant form. However IDEA doesn't report those results in its typical
      > > fashion. It uses its own custom runner to gather and run these tests.
      > >
      > > The only option I see in the JUnit current code is to make a custom
      > > runner that knows how to extract a Class[] array and pass it on to the
      > > standard runner, and then use the RunWith tag to annotate an arbitrary
      > > class to get IDEA to think that it is running a test suite. I haven't
      > > actually done this to see if IDEA has any issues, but it seems like it
      > > should work.
      > >
      > > My proposal is to add an annotation to the Suite class called
      > > SuiteMethod that would annotate a method that returns a Class[] array.
      > > The Suite would then be built from the two annotations,
      > > Suite.SuiteClasses plus any methods on the class (we could enforce
      > > that they be public, static, take no parameters and return a Class[]
      > > array) that are annotated with Suite.SuiteMethod and build the Suite
      > > as a combination of all of the Arrays returned.
      > >
      > > What do you think?
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      >
    • David Saff
      That s good feedback. While I agree that one runner with two mechanisms sounds simpler than two runners with one mechanism each, I also think that when you
      Message 2 of 5 , May 1 7:07 AM
        That's good feedback. While I agree that one runner with two
        mechanisms sounds simpler than two runners with one mechanism each, I
        also think that when you have two mechanisms, you have to address
        their interaction, which can lead to user confusion. Did you log a
        feature request? Thanks,

        David Saff

        On Fri, May 1, 2009 at 9:05 AM, yme0987654321 <yme0987654321@...> wrote:
        > I'm not sure what the motivation for having a separate runner would be. I suppose it could be called a DynamicSuite, or SuiteMethodRunner. I'm just not sure that it adds anything.
        >
        > Certainly from the user perspective I would see it as more intuitive to have one @RunWith(Suite.class) annotation with some variations on how to set up the suite rather than have two different runners and have to understand which one to use when.
        >
        > --- In junit@yahoogroups.com, David Saff <david@...> wrote:
        >>
        >> Sorry for the long delay in response.
        >>
        >> This is a good idea, I think.  I wonder if it needs to be in the same
        >> runner as Suite, or could it be a different Runner?
        >>
        >>    David Saff
        >>
        >> On Wed, Feb 25, 2009 at 10:34 AM, yme0987654321 <yme0987654321@...> wrote:
        >> > I have the following challenge, with a proposed solution. If there is
        >> > interest, I would be happy to contribute a patch to the JUnit project
        >> > to address it. On the other hand, if there is a way to solve this
        >> > problem differently in JUnit already, please let me know.
        >> >
        >> > Ant and IDEA (the IDE from Intellij) don't agree on how to gather
        >> > classes for test. IDEA inspects the actual class for things that
        >> > extend TestCase or have a JUnit annotation on the class (or have a
        >> > static suite method) and executes the test. Ant gathers tests via
        >> > class names. To use the Ant method with JUnit outside of Ant, you can
        >> > use JUnitCore, and just pass it an array of classes gathered in the
        >> > Ant form. However IDEA doesn't report those results in its typical
        >> > fashion. It uses its own custom runner to gather and run these tests.
        >> >
        >> > The only option I see in the JUnit current code is to make a custom
        >> > runner that knows how to extract a Class[] array and pass it on to the
        >> > standard runner, and then use the RunWith tag to annotate an arbitrary
        >> > class to get IDEA to think that it is running a test suite. I haven't
        >> > actually done this to see if IDEA has any issues, but it seems like it
        >> > should work.
        >> >
        >> > My proposal is to add an annotation to the Suite class called
        >> > SuiteMethod that would annotate a method that returns a Class[] array.
        >> > The Suite would then be built from the two annotations,
        >> > Suite.SuiteClasses plus any methods on the class (we could enforce
        >> > that they be public, static, take no parameters and return a Class[]
        >> > array) that are annotated with Suite.SuiteMethod and build the Suite
        >> > as a combination of all of the Arrays returned.
        >> >
        >> > What do you think?
        >> >
        >> >
        >> >
        >> >
        >> >
        >> >
        >> >
        >> > ------------------------------------
        >> >
        >> > Yahoo! Groups Links
        >> >
        >> >
        >> >
        >> >
        >>
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • yme0987654321
        I just logged it as 2786193. To me the interaction would be that a given class passed to the Suite runner would only be executed once (that is a Set rather
        Message 3 of 5 , May 3 11:29 AM
          I just logged it as 2786193.

          To me the interaction would be that a given class passed to the Suite runner would only be executed once (that is a Set rather than a List), but it does get into certain caveats, such as each one of those classes being suites themselves the test will run twice. So I certainly see the point about the interaction issue.

          My preference is still for the one Suite class because I just see it as a natural way to build a suite, but I don't know that I have a specific argument in favor of it.

          --- In junit@yahoogroups.com, David Saff <david@...> wrote:
          >
          > That's good feedback. While I agree that one runner with two
          > mechanisms sounds simpler than two runners with one mechanism each, I
          > also think that when you have two mechanisms, you have to address
          > their interaction, which can lead to user confusion. Did you log a
          > feature request? Thanks,
          >
          > David Saff
          >
          > On Fri, May 1, 2009 at 9:05 AM, yme0987654321 <yme0987654321@...> wrote:
          > > I'm not sure what the motivation for having a separate runner would be. I suppose it could be called a DynamicSuite, or SuiteMethodRunner. I'm just not sure that it adds anything.
          > >
          > > Certainly from the user perspective I would see it as more intuitive to have one @RunWith(Suite.class) annotation with some variations on how to set up the suite rather than have two different runners and have to understand which one to use when.
          > >
          > > --- In junit@yahoogroups.com, David Saff <david@> wrote:
          > >>
          > >> Sorry for the long delay in response.
          > >>
          > >> This is a good idea, I think.  I wonder if it needs to be in the same
          > >> runner as Suite, or could it be a different Runner?
          > >>
          > >>    David Saff
          > >>
          > >> On Wed, Feb 25, 2009 at 10:34 AM, yme0987654321 <yme0987654321@> wrote:
          > >> > I have the following challenge, with a proposed solution. If there is
          > >> > interest, I would be happy to contribute a patch to the JUnit project
          > >> > to address it. On the other hand, if there is a way to solve this
          > >> > problem differently in JUnit already, please let me know.
          > >> >
          > >> > Ant and IDEA (the IDE from Intellij) don't agree on how to gather
          > >> > classes for test. IDEA inspects the actual class for things that
          > >> > extend TestCase or have a JUnit annotation on the class (or have a
          > >> > static suite method) and executes the test. Ant gathers tests via
          > >> > class names. To use the Ant method with JUnit outside of Ant, you can
          > >> > use JUnitCore, and just pass it an array of classes gathered in the
          > >> > Ant form. However IDEA doesn't report those results in its typical
          > >> > fashion. It uses its own custom runner to gather and run these tests.
          > >> >
          > >> > The only option I see in the JUnit current code is to make a custom
          > >> > runner that knows how to extract a Class[] array and pass it on to the
          > >> > standard runner, and then use the RunWith tag to annotate an arbitrary
          > >> > class to get IDEA to think that it is running a test suite. I haven't
          > >> > actually done this to see if IDEA has any issues, but it seems like it
          > >> > should work.
          > >> >
          > >> > My proposal is to add an annotation to the Suite class called
          > >> > SuiteMethod that would annotate a method that returns a Class[] array.
          > >> > The Suite would then be built from the two annotations,
          > >> > Suite.SuiteClasses plus any methods on the class (we could enforce
          > >> > that they be public, static, take no parameters and return a Class[]
          > >> > array) that are annotated with Suite.SuiteMethod and build the Suite
          > >> > as a combination of all of the Arrays returned.
          > >> >
          > >> > What do you think?
          > >> >
          > >> >
          > >> >
          > >> >
          > >> >
          > >> >
          > >> >
          > >> > ------------------------------------
          > >> >
          > >> > Yahoo! Groups Links
          > >> >
          > >> >
          > >> >
          > >> >
          > >>
          > >
          > >
          > >
          > >
          > > ------------------------------------
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.