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

Re: [junit] Re: Misc improvements

Expand Messages
  • David Saff
    Marc, ... Actually, that would be a really interesting experiment. I hope you re right that the current voting at github drastically undercounts the number
    Message 1 of 12 , Feb 17, 2011
    View Source
    • 0 Attachment
      Marc,

      On Thu, Feb 17, 2011 at 12:00 PM, Marc Guillemot <mguillemot@...> wrote:
      > David,
      >
      > how many votes has the issue with the most votes? As far as I can check:
      > 17. This is clearly nothing compared to the JUnit user community what
      > clearly demonstrate for me that it is not the appropriate way to
      > evaluate an improvement (I'm quite sure that I could quickly motivate
      > far more than 17 users to vote for one issue but it would be biased).

      Actually, that would be a really interesting experiment. I hope
      you're right that the current voting at github drastically undercounts
      the number and passion of JUnit users.

      > Currently you "are" JUnit therefore I'd like to know from *you* what
      > *you* think of these suggestions. Or don't you use JUnit? ;-)

      I do use JUnit, and each of these suggestions looks potentially
      useful. However, each of them also could work just fine as an
      extension to JUnit. If I create a junit-contrib project soon for
      extensions outside the JUnit core, would you like to be one of the
      first contributors? Thanks,

      David Saff

      >
      > Cheers,
      > Marc.
      > --
      > HtmlUnit support & consulting from the source
      > Blog: http://mguillem.wordpress.com
      >
      > Le 14/02/2011 17:50, David Saff a écrit :
      >> Marc,
      >>
      >> Thanks for giving me incentive to write up the current state of the
      >> JUnit community, which I've posted under a different subject heading.
      >> If you have a chance to look there, and give thoughts on the general
      >> state, I hope you'll be able to see general change that will be less
      >> discouraging.
      >>
      >> In terms of these specific ideas, I had in mind that you could simply
      >> copy and paste each bullet line into a feature request, and post links
      >> to each feature here on the list, encouraging readers to vote.  That
      >> way, we could start with the most popular ideas, and iterate on clean
      >> patches for those, once you could be sure that the effort wouldn't be
      >> wasted.
      >>
      >> I hope that addresses your concerns.  Let me know,
      >>
      >>     David Saff
      >>
      >> On Mon, Feb 14, 2011 at 3:47 AM, mguillemot<mguillemot@...>  wrote:
      >>> Hi David,
      >>>
      >>> not really the most motivating answer :-(
      >>>
      >>> Providing a clean patch requires time. I follow JUnit GitHub issues since long enough to have an idea of what happens there, therefore I will use my time for other activities.
      >>>
      >>> Cheers,
      >>> Marc.
      >>>
      >>>
      >>> --- In junit@yahoogroups.com, David Saff<david@...>  wrote:
      >>>>
      >>>> Marc,
      >>>>
      >>>> After the release of 4.9 (hopefully soon), my plan is to concentrate
      >>>> development and patching activity on GitHub issues with high vote
      >>>> counts.  I recommend posting these as GitHub issues
      >>>> (http://github.com/KentBeck/junit/issues)--feel free to use this forum
      >>>> to encourage votes.  Thanks,
      >>>>
      >>>>     David Saff
      >>>>
      >>>> On Thu, Feb 10, 2011 at 12:09 PM, mguillemot<mguillemot@...>  wrote:
      >>>>> Hi,
      >>>>>
      >>>>> I would be interested to know if JUnit team would have interest in the features below for integration in JUnit. If yes, I would look at providing patches and if not, I'll find an other way to waste my time ;-)
      >>>>>
      >>>>> - ForkingVMTestRunner
      >>>>> a runner executing the unit tests in a forked virtual machine allowing to test effect of command line JVM switches for instance
      >>>>>
      >>>>> - ParrallelRunner
      >>>>> JUnit already contains nearly the whole code for that but not available as runner running tests in parallel
      >>>>>
      >>>>> - ParameterizedRunner
      >>>>> a runner far more flexible than JUnit's Parameterized runner allowing to configure usage per method (a bit like TestNG) and for different types
      >>>>>
      >>>>> - @NotYetImplemented
      >>>>> this is an annotation allowing to indicate that a unit test is expected to fail. A failure should be reported as success whereas a success should be reported as failure. This has proven to be far more interesting than @Ignore which is just a little better than removing a test: @NotYetImplemented allows to write tests for "accepted" bugs or future features and to get notified when they are fixed as side effect of other changes
      >>>>>
      >>>>> - assertEquals&  IDE integration
      >>>>> small improvement to throw ComparisonFailure not only for String comparison what allows IDE like Eclipse to better display differences between expected and actual result.
      >>>>>
      >>>>> Cheers,
      >>>>> Marc.
      >>>>>
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Marc Guillemot
      David, ... please be serious, everybody knows that it is an other order of magnitude! ... I have the unpleasant impression that you didn t really read the
      Message 2 of 12 , Feb 21, 2011
      View Source
      • 0 Attachment
        David,

        > ...
        > I hope
        > you're right that the current voting at github drastically undercounts
        > the number and passion of JUnit users.

        please be serious, everybody knows that it is an other order of magnitude!

        >> Currently you "are" JUnit therefore I'd like to know from *you* what
        >> *you* think of these suggestions. Or don't you use JUnit? ;-)
        >
        > I do use JUnit, and each of these suggestions looks potentially
        > useful. However, each of them also could work just fine as an
        > extension to JUnit.

        I have the unpleasant impression that you didn't really read the
        suggested improvements. At least one (probably two) of my propositions
        surely can't work as an extension to JUnit.

        > If I create a junit-contrib project soon for
        > extensions outside the JUnit core, would you like to be one of the
        > first contributors? Thanks,

        of course (if we spend time discussing about the content rather than
        about the form).

        Cheers,
        Marc.
        --
        HtmlUnit support & consulting from the source
        Blog: http://mguillem.wordpress.com
      • David Saff
        ... Marc, Yes, surely they can: ForkingVMTestRunner: additional runner ParameterizedRunner: additional runner NotYetImplemented: an additional annotation
        Message 3 of 12 , Feb 21, 2011
        View Source
        • 0 Attachment
          On Mon, Feb 21, 2011 at 4:44 AM, Marc Guillemot <mguillemot@...> wrote:
          > David,
          >
          >> ...
          >> I hope
          >> you're right that the current voting at github drastically undercounts
          >> the number and passion of JUnit users.
          >
          > please be serious, everybody knows that it is an other order of magnitude!
          >
          >>> Currently you "are" JUnit therefore I'd like to know from *you* what
          >>> *you* think of these suggestions. Or don't you use JUnit? ;-)
          >>
          >> I do use JUnit, and each of these suggestions looks potentially
          >> useful.  However, each of them also could work just fine as an
          >> extension to JUnit.
          >
          > I have the unpleasant impression that you didn't really read the
          > suggested improvements. At least one (probably two) of my propositions
          > surely can't work as an extension to JUnit.

          Marc,

          Yes, surely they can:

          ForkingVMTestRunner: additional runner
          ParameterizedRunner: additional runner
          NotYetImplemented: an additional annotation enabled by an additional
          Runner or additional Rule.
          assertEquals & IDE integration: an additional static assert method
          (when we change the built-in assertEquals, it breaks tests that have
          been running fine for years. This tends to cause Bad Days for already
          over-worked people. A separate static method is an easy way for
          people to opt-in to the new behavior)

          Most interesting is ParallelRunner. From your description, this
          appears to be a Runner that exposes the work already latent in the
          ParallelComputer class and others. It would be interesting if you had
          to make any changes to the existing classes in order to produce this
          new Runner without duplication. Thanks,

          David Saff

          > - ForkingVMTestRunner
          ? a runner executing the unit tests in a forked virtual machine
          allowing to test effect of command line JVM switches for instance

          - ParrallelRunner
          JUnit already contains nearly the whole code for that but not
          available as runner running tests in parallel

          - ParameterizedRunner
          a runner far more flexible than JUnit's Parameterized runner allowing
          to configure usage per method (a bit like TestNG) and for different
          types

          - @NotYetImplemented
          this is an annotation allowing to indicate that a unit test is
          expected to fail. A failure should be reported as success whereas a
          success should be reported as failure. This has proven to be far more
          interesting than @Ignore which is just a little better than removing a
          test: @NotYetImplemented allows to write tests for "accepted" bugs or
          future features and to get notified when they are fixed as side effect
          of other changes

          - assertEquals & IDE integration
          small improvement to throw ComparisonFailure not only for String
          comparison what allows IDE like Eclipse to better display differences
          between expected and actual result.

          >
          >> If I create a junit-contrib project soon for
          >> extensions outside the JUnit core, would you like to be one of the
          >> first contributors?  Thanks,
          >
          > of course (if we spend time discussing about the content rather than
          > about the form).
          >
          > Cheers,
          > Marc.
          > --
          > HtmlUnit support & consulting from the source
          > Blog: http://mguillem.wordpress.com
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • Marc Guillemot
          ... yes ... it could but it doesn t makes sense. As runners can t be composed, it should be handled at the root like @Ignored ... this doesn t make sense for
          Message 4 of 12 , Feb 21, 2011
          View Source
          • 0 Attachment
            Le 21/02/2011 16:44, David Saff a écrit :
            >...
            >
            > ForkingVMTestRunner: additional runner
            > ParameterizedRunner: additional runner

            yes

            > NotYetImplemented: an additional annotation enabled by an additional
            > Runner or additional Rule.

            it could but it doesn't makes sense. As runners can't be composed, it
            should be handled at the root like @Ignored

            > assertEquals& IDE integration: an additional static assert method
            > (when we change the built-in assertEquals, it breaks tests that have
            > been running fine for years. This tends to cause Bad Days for already
            > over-worked people. A separate static method is an easy way for
            > people to opt-in to the new behavior)

            this doesn't make sense for me at all.

            First who will call Assert.assertEquals in some cases and
            SomeUtils.assertEquals in other cases?

            Second, I'm quite sure that changing
            failNotEquals(message, expected, actual);
            to
            throw new ComparisonFailure(cleanMessage, String.valueOf(expected),
            String.valueOf(actual));

            wouldn't have the drawbacks you describe. Even better it would align the
            code to what is currently done for Strings.

            > Most interesting is ParallelRunner. From your description, this
            > appears to be a Runner that exposes the work already latent in the
            > ParallelComputer class and others. It would be interesting if you had
            > to make any changes to the existing classes in order to produce this
            > new Runner without duplication.

            just make the anonymous RunnerScheduler in ParallelComputer.parallelize
            reusable and it's done.

            This was my last email on this subject. This is clear to me that you are
            not interested in what I propose. I'm not really surprised as it
            confirms the experience made by others in the past. This is sad because
            I still think that a lot of JUnit users would love improvements but at
            the end, it is your decision.

            Cheers,
            Marc.
            --
            HtmlUnit support & consulting from the source
            Blog: http://mguillem.wordpress.com
          • David Saff
            Marc, ... But Rules can be composed. ... Changing AssertionFailedException to AssertError as part of the upgrade from JUnit 3 to JUnit 4 internally to Google
            Message 5 of 12 , Feb 21, 2011
            View Source
            • 0 Attachment
              Marc,

              On Mon, Feb 21, 2011 at 11:17 AM, Marc Guillemot <mguillemot@...> wrote:
              > Le 21/02/2011 16:44, David Saff a écrit :
              >>...
              >>
              >> ForkingVMTestRunner: additional runner
              >> ParameterizedRunner: additional runner
              >
              > yes
              >
              >> NotYetImplemented: an additional annotation enabled by an additional
              >> Runner or additional Rule.
              >
              > it could but it doesn't makes sense. As runners can't be composed, it
              > should be handled at the root like @Ignored

              But Rules can be composed.

              >
              >> assertEquals&  IDE integration: an additional static assert method
              >> (when we change the built-in assertEquals, it breaks tests that have
              >> been running fine for years.  This tends to cause Bad Days for already
              >> over-worked people.  A separate static method is an easy way for
              >> people to opt-in to the new behavior)
              >
              > this doesn't make sense for me at all.
              >
              > First who will call Assert.assertEquals in some cases and
              > SomeUtils.assertEquals in other cases?
              >
              > Second, I'm quite sure that changing
              >   failNotEquals(message, expected, actual);
              > to
              >   throw new ComparisonFailure(cleanMessage, String.valueOf(expected),
              > String.valueOf(actual));
              >
              > wouldn't have the drawbacks you describe. Even better it would align the
              > code to what is currently done for Strings.

              Changing AssertionFailedException to AssertError as part of the
              upgrade from JUnit 3 to JUnit 4 internally to Google broke dozens of
              test suites. People write custom assertion packages, and then write
              tests for those packages. I'm quite sure that this change would have
              a similar effect, multiplied by a much wider user base. It would be
              odd to me to assert both that this change is so useful, it's worth the
              potential breakage, but so useless, no one would be willing to change
              their static imports to use it.

              If we were to make this available in junit-contrib, we could see how
              wide its usage was, and then have data to add to the discussion, not
              just the force of our convictions.

              >> Most interesting is ParallelRunner.  From your description, this
              >> appears to be a Runner that exposes the work already latent in the
              >> ParallelComputer class and others.  It would be interesting if you had
              >> to make any changes to the existing classes in order to produce this
              >> new Runner without duplication.
              >
              > just make the anonymous RunnerScheduler in ParallelComputer.parallelize
              > reusable and it's done.

              I'd welcome a patch to do this.

              > This was my last email on this subject. This is clear to me that you are
              > not interested in what I propose. I'm not really surprised as it
              > confirms the experience made by others in the past. This is sad because
              > I still think that a lot of JUnit users would love improvements but at
              > the end, it is your decision.

              Marc,

              I invited you to submit your ideas to the same process that everyone
              else's ideas are evaluated. You responded that responsiveness in that
              arena was lacking. I spent a long time thinking about that, and sent
              a long response entitled "JUnit issue responsiveness", where I tried
              to directly discuss the "experience made by others in the past", and
              my plans for improving it. I have invited you to contribute to those
              plans. I have, in total, spent several hours addressing these ideas
              of yours, at no cost to yourself, not even the time it would have
              taken you to copy and paste your ideas over to github.

              Every addition into the core JUnit jar has a cost, as well as a
              benefit, to future maintainers, extenders, and users. At this point,
              I do not think that changing to a model in which someone mails five
              one-line ideas to a mailing list, and I simply say "sure, I'll accept
              all of those patches if you write them" would be beneficial to
              everyone involved. Please, try to convince me otherwise, ideally over
              at the thread "JUnit issue responsiveness", so I can learn from your
              experiences.

              I'm sorry if this does not appear to you to be "interest". I truly
              hope that you, or other interested users, can partner with me to take
              JUnit forward, and welcome your contributions in the future.

              David Saff

              >
              > Cheers,
              > Marc.
              > --
              > HtmlUnit support & consulting from the source
              > Blog: http://mguillem.wordpress.com
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
            • Malte Finsterwalder
              Hi Marc, ... I don t see, that David does not have any interest in accepting your changes. I too feel, that he is trying hard to find a way to accomodate your
              Message 6 of 12 , Feb 22, 2011
              View Source
              • 0 Attachment
                Hi Marc,

                > This was my last email on this subject. This is clear to me that you are
                > not interested in what I propose. I'm not really surprised as it
                > confirms the experience made by others in the past. This is sad because
                > I still think that a lot of JUnit users would love improvements but at
                > the end, it is your decision.

                I don't see, that David does not have any interest in accepting your
                changes. I too feel, that he is trying hard to find a way to
                accomodate your changes.
                But yes, this accomodation is not: We will build it all into JUnit.
                And that's ok for me (as a JUnit user).
                If that's the only acceptable answer for you, than I feel sorry, that
                we all can't benefit from your contributions.

                Kent Beck and David Saff work hard not to break existing usage of
                JUnit. That's a deliberate decision and it's quite reasonable,
                considering the large user base, that JUnit has. They also work hard
                to keep JUnit itself small (lean and mean), so it can be maintained
                and developed easily. They built lots of extension mechanisms to allow
                for the type of contributions, that you would like to make.
                If these extension mechanisms are not quite enough yet, then I would
                work to improve those in the JUnit core. (Combinable Runners might be
                one of those things, that are missing yet.)

                Greetings,
                Malte
              Your message has been successfully submitted and would be delivered to recipients shortly.