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

RE: [junit] Digest Number 1845

Expand Messages
  • Ilja Preuss
    ... The current datasheet states that using Agitator is more effective than writing tests manually. If I remember correctly, an earlier version more directly
    Message 1 of 12 , Jun 1, 2006
    View Source
    • 0 Attachment
      >> Moreover I fear a tool that can figure out tests for you may give
      >> developers an excuse not to write their own tests; especially if it
      >> is marketed to managers and developers as a way to reduce unit test
      >> writing time.
      >
      >
      > I share this concern and I am trying to ascertain whether it
      > is marketed this way or if it is a misunderstanding on the
      > part of those being marketed to.

      The current datasheet states that using Agitator is more effective than
      writing tests manually.

      If I remember correctly, an earlier version more directly stated that the
      high number of tests you had to write for TDD was a problem that is solved
      by using Agitator.

      Take care, Ilja
    • Elliotte Harold
      ... The system did not work just fine. As you point out, developers would not and could not operate this way. This wasn t a problem with your developers. It
      Message 2 of 12 , Jun 1, 2006
      View Source
      • 0 Attachment
        albsavoia wrote:

        > Not exactly test first, but the same basic idea: the code was not
        > "done" until the tests (generated directly from the spec therefore
        > in-sync with the spec) passed.
        >
        > The system worked just fine, but there was a big problem. Most
        > developers did not want to write specs first. Let me be more
        > specific: some of them did not want to, others could not do it. Some
        > developers, including some very good ones, are not wired to think test
        > first. They could do it, but they would not be very effective at it -
        > like asking a left-handed person to write with their write hand.
        >

        The system did not work just fine. As you point out, developers would
        not and could not operate this way. This wasn't a problem with your
        developers. It was a problem with your process.

        I have *never* met a competent developer who was incapable of doing test
        first development once introduced to it. The reason you couldn't get
        developers to follow your system is precisely that it wasn't test first
        development. You were asking for big up-front design, and we know from
        experience that doesn't work. I am not surprised that you encountered
        resistance when asking programmers to produce this level of design
        before writing code.

        The proper way to do test first development is to write *one* test, just
        one. Then code until the test passes. Then write another test. Then code
        until it passes. Repeat until the application is done.

        You don't have to be a total stickler about this. Sometimes you can
        write a few tests before writing the code to make them pass. Sometimes
        you can write a somewhat more generic version of a method than is
        strictly needed to make a test pass. However the two extremes--all code
        before any tests or all tests before any code--are completely
        dysfunctional modes of operation. Normally we're arguing against the
        former position--all code before testing--because it's the more common
        pathology. However the opposite is equally pathological, just not as
        often seen.

        --
        Elliotte Rusty Harold elharo@...
        Java I/O 2nd Edition Just Published!
        http://www.cafeaulait.org/books/javaio2/
        http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
      • Elliotte Harold
        ... Interesting post. One of the no-design-by-contract cases you mention there is The update of an internal XML representation. Actually XOM uses design by
        Message 3 of 12 , Jun 1, 2006
        View Source
        • 0 Attachment
          Cédric Beust ♔ wrote:

          > More details here <http://www.jroller.com/page/cbeust/20021213> (I wrote
          > this four years ago, but my points still stand).

          Interesting post. One of the no-design-by-contract cases you mention
          there is "The update of an internal XML representation."

          Actually XOM uses design by contract principles quite heavily. Since
          Java doesn't support conditions and invariants as language level
          constructs, this has to be done with explicit code, JavaDoc, and unit
          tests. However DBC is absolutely in the front of my mind when I'm
          working on XOM.


          --
          Elliotte Rusty Harold elharo@...
          Java I/O 2nd Edition Just Published!
          http://www.cafeaulait.org/books/javaio2/
          http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
        • albsavoia
          ... Hi Cedric, good to see you too - we should follow-up on that plan we talked about well over a year ago and meet in person. ... Well said. There are obvious
          Message 4 of 12 , Jun 2, 2006
          View Source
          • 0 Attachment
            --- In junit@yahoogroups.com, "Cédric Beust â™" " <cbeust@...> wrote:
            > Hi Alberto, good to see you again,

            Hi Cedric, good to see you too - we should follow-up on that plan we
            talked about well over a year ago and meet in person.

            >The important point here is that this developer needs to agree
            > that writing tests is part of her job. At least to a certain extent.

            Well said.

            There are obvious disagreements and mis-understandings about the ways
            developers should test: manual/automated, test first/during/after,
            test-some/test-everything, etc., but we all seem to agree that some
            (non-trivial) amount of testing is part of a developer's job. This is
            not a surprising result given the sample of people who participate in
            this forum. What is somewhat surprising is that today most developers
            will readily agree with that statement as well (this would not have
            been the case 5-10 years ago).

            There is, however, a difference between agreeing with something and
            practicing it. The state of affairs today is that most software
            development organizations and individual developers agree that
            developer testing is the right thing to do - but very few actually do
            it, or do it well enough. I call this "The Developer Testing Paradox"
            and wrote about in some detail on developertesting.com:

            http://www.developertesting.com/archives/month200501/20050127-TheDeveloperTestingParadox.html

            What I see on this forum (and others) is that we (the thought leaders
            and active promoters of developer testing) spend too much time arguing
            with each-other about the best way to do developer testing instead of
            agreeing on the common ground and joining forces to promote the core
            idea that we all agree upon.

            If I was a developer exploring the idea of unit testing and wanting to
            learn more about it and JUnit/TestNG/Agitator/you-name-it, I would
            find some of the arguments we have to be a turn-off: "I'd really like
            to try developer testing, but these people can't even agree amongst
            themselves on how to go about it."

            I believe it's fine and healthy to have differing opinions and believe
            in different approaches to developer testing, but I can't help
            thinking that, compared to the reality that the vast majority of
            developers and organizations are not practicing developer testing in
            the first place, we are splitting hairs.

            I believe the best way to grow the ranks of people who become test
            infected is to lower the barriers to entry, to offer a variety of
            approaches to suit most tastes and preferences:

            Test-first or test-last? Either one as long as you test.
            JUnit or TestNG? Whatever feels most natural to you.
            Manual or Automated? Take your pick, mix-and-match, both are good.

            Instead of attacking or confronting people who bring other approaches,
            views, and tools to the table, we should welcome them because we need
            more people on our side and more/better tools and options to get more
            people to join the ranks of test-infected developers.

            In my opinion, our ranks are still too small for us to act in a
            divisive way, make the entry barrier too high, or be too inflexible
            about the way people choose to approach their testing.

            Alberto
          • whitworthjanet
            I agree with you completely. The thing we need to focus on is anything that we can do to get them started testing. The argument I constantly hear from
            Message 5 of 12 , Jun 2, 2006
            View Source
            • 0 Attachment
              I agree with you completely. The thing we need to focus on is anything
              that we can do to get them started testing. The argument I constantly
              hear from developers is that they don't have time. My personal
              experience is that testing actually saves me time. We need some way to
              get the non-believers to try it themselves, so they will see.

              My preference is to adopt an organic approach to gradually incorporate
              unit testing into the project. I emphasize the importance of building
              junit tests before modifying existing code. It isn't essential that
              they be write isolated unit tests, when the components of the class
              are known to work. Instead focus on testing the API of the class in
              any way that it can possibly change due to the modifications. Before
              fixing a bug, write a junit test that fails. This proves that the
              cause of the bug is known and once the code is modified, that the bug
              is fixed. When they see how easy it is to test at the unit level
              rather than the user interface, hopefully they will become sold.

              Janet
            • Elliotte Harold
              ... No. It s not a trivial or unimportant difference. testing first is radically different than testing last. It is not just about testing. It is about
              Message 6 of 12 , Jun 2, 2006
              View Source
              • 0 Attachment
                albsavoia wrote:

                > Test-first or test-last? Either one as long as you test.

                No. It's not a trivial or unimportant difference. testing first is
                radically different than testing last. It is not just about testing. It
                is about developing and understanding the code you;re going to write. It
                is about speeding up the development process.

                Test last is the traditional approach, and it doesn't even have the same
                goals.

                > JUnit or TestNG? Whatever feels most natural to you.

                Sure.

                > Instead of attacking or confronting people who bring other approaches,
                > views, and tools to the table, we should welcome them because we need
                > more people on our side and more/better tools and options to get more
                > people to join the ranks of test-infected developers.
                >

                The sides are not where you think they are. No one here is arguing
                against the relevance of QA departments and testing. However test first
                development is primarily about *development*, not testing. It is a
                programming strategy. That strategy depends critically on writing the
                unit tests in sync with the code. It depends critically on applying
                human intelligence to the code so the *humans* develop better
                understanding of what they want. These are not side issues. They are at
                the core of test driven development.

                --
                Elliotte Rusty Harold elharo@...
                Java I/O 2nd Edition Just Published!
                http://www.cafeaulait.org/books/javaio2/
                http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
              • albsavoia
                ... Hi Elliotte, I understand the concept and mission of Test-First/TDD, support its use in-house, and I ve had some personal successes with it. I also try to
                Message 7 of 12 , Jun 2, 2006
                View Source
                • 0 Attachment
                  --- In junit@yahoogroups.com, Elliotte Harold <elharo@...> wrote:
                  > > Instead of attacking or confronting people who bring other approaches,
                  > > views, and tools to the table, we should welcome them because we need
                  > > more people on our side and more/better tools and options to get more
                  > > people to join the ranks of test-infected developers.
                  > >
                  >
                  > The sides are not where you think they are. No one here is arguing
                  > against the relevance of QA departments and testing. However test first
                  > development is primarily about *development*, not testing. It is a
                  > programming strategy. That strategy depends critically on writing the
                  > unit tests in sync with the code. It depends critically on applying
                  > human intelligence to the code so the *humans* develop better
                  > understanding of what they want. These are not side issues. They are at
                  > the core of test driven development.

                  Hi Elliotte,

                  I understand the concept and mission of Test-First/TDD, support its
                  use in-house, and I've had some personal successes with it. I also
                  try to make sure that the tools we develop try to support some mode of
                  TDD. But TDD is not the battle I am choosing to personally fight.
                  First because there are many other people more qualified, more
                  passionate, and more convinced than I am about its benefits and
                  general/broad applicability (just look at this forum). Second,
                  because I believe that the best way to get developers to consider and
                  appreciate TDD or other "more rigorous" forms/disciplines of
                  design/testing is to get them to consider and appreciate testing in
                  the first place; and accept that testing their own code is a
                  professional responsibility (I like Bob Martin's analogy of doctors
                  having to wash their hands before surgery).

                  When I say "Test-first or test-last? Either one as long as you test",
                  I am not saying that there's no difference betweeen the two
                  approaches, or trivializing it. I am saying, that as far as I am
                  concerned, both approaches are OK with me. Either approach is a big
                  improvement over the current situations where most developers don't
                  test. I am trying to bring developers in the testing camp in the
                  first place, once in the camp they can start to appreciate the value
                  of testing and then decide for themselves if test-first is for them.

                  In summary: I am most interested/passionate in getting developers to
                  take responsibility for testing their code - writing tests for testing
                  sake if you will. I see people who practice and promote TDD as allies;
                  I understand and respect their beliefs and practices, but I also
                  accept, understand, and welcome people who don't want to practice TDD.

                  Do you believe that promoting the idea of developer testing without
                  directly promoting TDD (i.e. saying that if developers write tests
                  they should only write them before the code) harms the TDD cause?

                  Or that mentioning test-first in a more general "developers should
                  write tests" message "cheapens" TDD because TDD is about design and
                  not testing?

                  I am asking these questions not to start/continue an argument. I
                  sincerely want to understand where you stand.

                  Alberto
                Your message has been successfully submitted and would be delivered to recipients shortly.