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

New poll for extremeprogramming

Expand Messages
  • extremeprogramming@egroups.com
    Enter your vote today! Check out the new poll for the extremeprogramming group: Do we call the tests specified/written by the customer functional tests or
    Message 1 of 276 , Apr 5, 2000
    • 0 Attachment
      Enter your vote today! Check out the new poll for the extremeprogramming
      group:


      Do we call the tests specified/written
      by the customer "functional tests"
      or "acceptance tests"?

      o Functional tests
      o Acceptance tests


      To vote, please visit the following web page:

      http://www.egroups.com/polls/extremeprogramming

      Note: Please do not reply to this message. Poll votes are
      not collected via email. To vote, you must go to the eGroups
      web site listed above.

      Thanks!
    • John Carter
      ... Aha! Ok, got it. Thanks for a good reply. Curiously enough when I do Design by Contract, I don t use any DbC tool except assert macros (or what useful
      Message 276 of 276 , Jun 2, 2008
      • 0 Attachment
        On Mon, 2 Jun 2008, Julian Hall wrote:

        > --- In extremeprogramming@yahoogroups.com, John Carter

        >> On Sat, 31 May 2008, Julian Hall wrote:
        >>
        >>> There's a missing option in the poll, which most closely describes the
        >>> way I feel: "I would use it, but it makes refactoring harder."
        >>
        >> Ah! This is exactly the sort of thing I wanted to shake loose!
        >>
        >> Now if you could explain why you believe that, it would be very
        > interesting.
        >
        > Many refactorings change pre and post conditions for the methods they
        > are applied to. When those conditions are specified as part of a unit
        > test, an automated refactoring tool can update them directly. If the
        > conditions are specified either as documentation or using some formal
        > notation that isn't part of the language supported by the automated
        > tool, this adds manual work to the process.
        >
        > I'm not aware of any way of annotating the code with such conditions
        > that can be refactored automatically.

        Aha! Ok, got it. Thanks for a good reply.

        Curiously enough when I do Design by Contract, I don't use any DbC tool
        except "assert" macros (or what useful variations the language or I
        can provide).

        The assert expressions are simple, ordinary C/Java/Ruby/... and as
        Good fodder for any refactoring tool as any other C/Java/Ruby... code.

        To me DbC is something that informs my design choices, and aids my
        debugging. I have totally divorced it from any "program proving"
        notion.

        >> Whenever I start refactoring I sprinkling the code with a good bracing
        >> of pre/post/invariant asserts documenting (in an executable way) how I
        >> believe the internals of this stuff is working (or should work.)
        >>
        >> I then run the unit tests, maybe adding a few more unit tests along
        >> the way.
        >>
        >> Often this phase coughs up a few false assumptions that I
        >> made, or finds pre-existing bugs.
        >
        > This is a good point. The process of examining the code to add the
        > assertions is a good third look at the code from yet another direction
        > entirely (the first two being unit tests and implementation), and will
        > show up errors. That's definitely worth considering. When I worked
        > with design by contract before, the conditions were the starting
        > point, described fully before any implementation was done. Perhaps
        > adding them afterwards is more useful.

        I do Test Driven Development a little funny...

        I write the test to drive the code.... without any asserts.

        Compile / run / fail haven't written the code under test (so far,
        still standard).

        I then write the signature for the class (no instance variables yet)
        and it's methods under test. (Now I start to diverge from the standard
        notion of TDD)

        I may insert a smattering of precondition asserts if I have a strong
        feeling of what I want coming through as parameters.

        Compile / Run / Pass! (Unless I have a bug in the test harness triggered by the precond assert).

        I then put the post condition asserts into the unit test.

        Compile / Run/ Fail.

        I then write the actual code.

        Hmm. This will only work if this instance variable is in this range
        limited by that variable...

        Add that to the invariant check.

        Compile / Run / Fail! Hah! Found bug!

        Fix! Compile / Run / Pass!

        Hmm. I detect a smell or two...

        Do I really understand what I'm doing... at in a few more precond
        asserts, both in the service I'm writing, and in the services it is a
        client of.


        Compile / Run /Fail / Fix.

        Refactor hack and slash.

        Compile / Run/ Fail and fix and iterate until pass.

        Now I feel I really understand what I'm doing, add more invariant
        checks, more preconds in the code, more post conds in the unit test.

        Start writing the next service that uses the service I have just written....

        Oo! Looky, I have this marvelous brace of asserts _inside_ the code, I
        don't need a mock object, and I already have a well designed set of
        tests being applied to my new object!

        >> I find this doubly valuable in a dynamic language without static type
        >> checking. like Ruby.
        >>
        >
        > A few years ago, I was a determined fan of dynamic languages. Now,
        > I'm not so sure. I like static typing: it makes my tools more powerful.

        I still like Ruby, but I'm not shy to throw in precondition asserts
        that do static type checks, polymorphic types checks or even "quacks
        like" duck typing checks as and when needed.

        Constructors and any other place where you stash state for use later
        is a Good place for them.

        >> The important aspect of DbC and refactoring is DbC informs my design
        >> taste. What is a Good Destination for a refactoring? One in which my
        >> Invariant is better protected.
        >>
        >> What is a Code Smell? A design where my invariant can be clobbered by
        >> client code.
        >
        > Interesting. Yes, I can see how this helps write more robust code.

        Ah, in fact it is why I voted that understanding DbC should be a core
        Agile value.

        We want, we must have robust, flexible code to be Agile.

        You _cannot_ be flexible and Agile if your classes leak their
        invariant to surrounding classses. If the responsibility for
        maintaining the integrity of internal state of one class has leaked to
        others. You have a rigid defect ridden system that breaks every time
        you attempt reuse or refactoring.


        John Carter Phone : (64)(3) 358 6639
        Tait Electronics Fax : (64)(3) 359 4632
        PO Box 1645 Christchurch Email : john.carter@...
        New Zealand
      Your message has been successfully submitted and would be delivered to recipients shortly.