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

RE: [XP] Test Objectives (was: Re: Unit Test Challenge II)

Expand Messages
  • Charlie Poole
    ... Yeah... this is more subtle than I would have thought. Generally, I ve emphasized never trusting your inputs. It s often proven to be necessary but that
    Message 1 of 263 , Mar 31, 2002
    • 0 Attachment
      Ron wrote:

      > So we write a simple algorithm that works when given the right input,
      > and then we glom it up with assertions or other forms of checking.
      >
      > Instead, since on an XP team there /is/ no *someone else*, why don't
      > we "just" keep writing simple algorithms that all work when given the
      > right input, thus causing all parts of the system to give each other
      > the right input, and wind up with a program that works because it's
      > correct, not because it's paranoid?

      And later:

      > I suggest that it's a deep question and that the easy answers aren't
      > getting at everything, either my notion of writing non-defensive code,
      > nor the reasons why, and why not, to do assertions.

      Yeah... this is more subtle than I would have thought. Generally, I've
      emphasized never trusting your inputs. It's often proven to be necessary
      but that was because they really couldn't be trusted.

      So _what_if_ they could be trusted? Then I think I might only use asserts
      or other checks for certain specific reasons:
      * If it made the programming go faster. Example: my object is called
      by legacy code that doesn't have unit tests and my assert displays a
      stack trace to allow discovering where the bad call originated.
      * If my code was being pulled out for reuse across multiple projects
      and needed a higher level of bullet-proofing.
      * If an error could cause serious damage and there was no better
      way to handle it.
      * Maybe others....

      Maybe the key question is "Should we spend time protecting against
      bad code or writing good code?"

      Charlie Poole
      cpoole@...
    • Ilja Preuß
      ... I don t write many asserts or comments, but *I* would most often prefer asserts before comments because - I always first look at the code if I want to know
      Message 263 of 263 , Apr 6, 2002
      • 0 Attachment
        > Why don't you replace the asserts with comments?

        I don't write many asserts or comments, but *I* would most often prefer
        asserts before comments because

        - I always first look at the code if I want to know what it does. If a
        precondition is significant enough to be written down, it is probably
        significant enough to be spotted early.

        - I most often find it easier to articulate something about code *in*
        code than in natural language.

        - I think if I *don't* find it easy to articulate a significant concept
        about the code in code, that tells me something about the design.

        - Even if I find it easy to articulate an assertion, writing it down
        might nevertheless tell me something about the design I didn't smell
        before.

        - I almost always find it easier to understand code than to understand
        natural language.

        - I am more likely to forget adjusting a comment to changing code than
        adjusting an assert.

        - I think it is easier to refactor an assertion than to refactor a
        comment

        - I simply hate writing comments, whereas I love writing code! ;-)

        There are probably more reasons...

        Regards, Ilja
      Your message has been successfully submitted and would be delivered to recipients shortly.