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

Re: JUnit 4.11-beta-1 is released

Expand Messages
  • Paul Holser
    Marc, I agree that Hamcrest is a terrific library for expressing expected test outcomes. So is FEST-Assert. If my tests are small and focused enough, I might
    Message 1 of 17 , Nov 1, 2012
      Marc, I agree that Hamcrest is a terrific library for expressing expected test outcomes. So is FEST-Assert. If my tests are small and focused enough, I might even roll with native Java assertions. The AssertionError (or, really, any exception that propagates out of a test) represents sort of an implicit contract between test and runner: signal the test as failed if the exception makes it out of the test unhandled. There are lots of ways to satisfy that contract; I'm not sure that one based on Hamcrest has to be the answer.

      The time period between JUnit 4.4 and 4.11 was challenging for those developers who wanted some of the goodness of Hamcrest > 1.1, what with the attendant Maven exclusions, surprising failures, and so forth. It led me to wonder whether Assert/Assume ought to be separate from the core of JUnit. Then, the putative "junit-assertions" module could depend on Hamcrest if it so chose, and "junit-core" (made-up module that doesn't exist right now) wouldn't have to. Further, developers could choose to use junit-assertions or not; Hamcrest alone (with MatcherAssert.assertThat()) or not; FEST-Assert, etc.

      I think of AssumptionViolatedException as another implicit contract between test and runner. Right now, though, unless you want to depend on a public-but-not-published AssumptionViolatedException class that you need Hamcrest to use, org.junit.Assume is the only way to satisfy that contract. Better would be to have AssumptionViolatedException be part of "junit-core", not depending on Hamcrest, and letting Assume live in "junit-assertions" and handle the Hamcrest matching.

      I'll send more under separate cover, maybe as a GitHub issue, as this doesn't pertain so much to JUnit 4.11 beta 1 as it does a consideration for the next major version of JUnit. I think it'd be interesting to explore segmenting JUnit into a multi-module project with dependencies teased out a bit.

      Thanks again for your excellent work and stewardship!

      --p


      --- In junit@yahoogroups.com, Marc Philipp <mphilipp82@...> wrote:
      >
      > From my very personal point-of-view I cannot imagine using JUnit without
      > Hamcrest anymore.
      >
      > @Paul: What would be the benefit of "breaking the dependency" entirely?
      >
      > @Mirko: Why shouldn't you be able to use a different version of Hamcrest?
      >
      > Regards, Marc
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • Paul King
      +1 on the creation of a junit-core (or whatever name but without Hamcrest as a requirement) Cheers, Paul.
      Message 2 of 17 , Nov 1, 2012
        +1 on the creation of a junit-core (or whatever name but without Hamcrest as a requirement)

        Cheers, Paul.

        On 2/11/2012 6:59 AM, Paul Holser wrote:
        > Marc, I agree that Hamcrest is a terrific library for expressing expected test outcomes. So is FEST-Assert. If my tests are small and focused enough, I might even roll with native Java assertions. The AssertionError (or, really, any exception that propagates out of a test) represents sort of an implicit contract between test and runner: signal the test as failed if the exception makes it out of the test unhandled. There are lots of ways to satisfy that contract; I'm not sure that one based on Hamcrest has to be the answer.
        >
        > The time period between JUnit 4.4 and 4.11 was challenging for those developers who wanted some of the goodness of Hamcrest > 1.1, what with the attendant Maven exclusions, surprising failures, and so forth. It led me to wonder whether Assert/Assume ought to be separate from the core of JUnit. Then, the putative "junit-assertions" module could depend on Hamcrest if it so chose, and "junit-core" (made-up module that doesn't exist right now) wouldn't have to. Further, developers could choose to use junit-assertions or not; Hamcrest alone (with MatcherAssert.assertThat()) or not; FEST-Assert, etc.
        >
        > I think of AssumptionViolatedException as another implicit contract between test and runner. Right now, though, unless you want to depend on a public-but-not-published AssumptionViolatedException class that you need Hamcrest to use, org.junit.Assume is the only way to satisfy that contract. Better would be to have AssumptionViolatedException be part of "junit-core", not depending on Hamcrest, and letting Assume live in "junit-assertions" and handle the Hamcrest matching.
        >
        > I'll send more under separate cover, maybe as a GitHub issue, as this doesn't pertain so much to JUnit 4.11 beta 1 as it does a consideration for the next major version of JUnit. I think it'd be interesting to explore segmenting JUnit into a multi-module project with dependencies teased out a bit.
        >
        > Thanks again for your excellent work and stewardship!
        >
        > --p
        >
        > --- In junit@yahoogroups.com <mailto:junit%40yahoogroups.com>, Marc Philipp <mphilipp82@...> wrote:
        > >
        > > From my very personal point-of-view I cannot imagine using JUnit without
        > > Hamcrest anymore.
        > >
        > > @Paul: What would be the benefit of "breaking the dependency" entirely?
        > >
        > > @Mirko: Why shouldn't you be able to use a different version of Hamcrest?
        > >
        > > Regards, Marc
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        >
        >
      • Marc Philipp
        ... Paul, I like the idea, you have my support. Please go ahead and open an issue for it. Thanks, Marc
        Message 3 of 17 , Nov 2, 2012
          > I'll send more under separate cover, maybe as a GitHub issue, as this doesn't pertain so much to JUnit 4.11 beta 1 as it does a consideration for the next major version of JUnit. I think it'd be interesting to explore segmenting JUnit into a multi-module project with dependencies teased out a bit.

          Paul,

          I like the idea, you have my support. Please go ahead and open an issue for it.

          Thanks, Marc
        • Mirko Friedenhagen
          Hello everyone, sounds like a good plan. To be backwards-compatible junit should depend on hamcrest, however. Otherwise we have to increase the major version
          Message 4 of 17 , Nov 2, 2012
            Hello everyone,

            sounds like a good plan. To be backwards-compatible junit should
            depend on hamcrest, however. Otherwise we have to increase the major
            version number.

            junit could then be a project only consisting of dependencies without
            any (Java-) source, right?

            junit depends on junit-core
            depends on junit-assertions depends on hamcrest

            +1 for making AssumptionViolatedException non-internal and putting
            org.junit.Assume into junit-assertions as well. Throwing an exception
            is no real biggy. I refrained from doing so because the package
            indicated AssumptionViolatedException to be internal.

            Regards Mirko


            On Thu, Nov 1, 2012 at 9:59 PM, Paul Holser <pholser@...> wrote:
            > Marc, I agree that Hamcrest is a terrific library for expressing expected test outcomes. So is FEST-Assert. If my tests are small and focused enough, I might even roll with native Java assertions. The AssertionError (or, really, any exception that propagates out of a test) represents sort of an implicit contract between test and runner: signal the test as failed if the exception makes it out of the test unhandled. There are lots of ways to satisfy that contract; I'm not sure that one based on Hamcrest has to be the answer.
            >
            > The time period between JUnit 4.4 and 4.11 was challenging for those developers who wanted some of the goodness of Hamcrest > 1.1, what with the attendant Maven exclusions, surprising failures, and so forth. It led me to wonder whether Assert/Assume ought to be separate from the core of JUnit. Then, the putative "junit-assertions" module could depend on Hamcrest if it so chose, and "junit-core" (made-up module that doesn't exist right now) wouldn't have to. Further, developers could choose to use junit-assertions or not; Hamcrest alone (with MatcherAssert.assertThat()) or not; FEST-Assert, etc.
            >
            > I think of AssumptionViolatedException as another implicit contract between test and runner. Right now, though, unless you want to depend on a public-but-not-published AssumptionViolatedException class that you need Hamcrest to use, org.junit.Assume is the only way to satisfy that contract. Better would be to have AssumptionViolatedException be part of "junit-core", not depending on Hamcrest, and letting Assume live in "junit-assertions" and handle the Hamcrest matching.
            >
            > I'll send more under separate cover, maybe as a GitHub issue, as this doesn't pertain so much to JUnit 4.11 beta 1 as it does a consideration for the next major version of JUnit. I think it'd be interesting to explore segmenting JUnit into a multi-module project with dependencies teased out a bit.
            >
            > Thanks again for your excellent work and stewardship!
            >
            > --p
            >
            >
            > --- In junit@yahoogroups.com, Marc Philipp <mphilipp82@...> wrote:
            >>
            >> From my very personal point-of-view I cannot imagine using JUnit without
            >> Hamcrest anymore.
            >>
            >> @Paul: What would be the benefit of "breaking the dependency" entirely?
            >>
            >> @Mirko: Why shouldn't you be able to use a different version of Hamcrest?
            >>
            >> Regards, Marc
            >>
            >>
            >> [Non-text portions of this message have been removed]
            >>
            >
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.