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

225Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Shae Matijs Erisson
    Apr 4, 2005
    • 0 Attachment
      Rob Nagler <nagler@...> writes:

      > There are several camps, and there is lots of data supporting both of
      > them. Here's an interesting study supporting partition testing over
      > proportional or random testing:
      >
      > http://www.chillarege.com/fastabstracts/issre99/99122.pdf

      I read this paper, and its [6] reference.
      It looks to me like these guys are saying that for the same number of tests,
      partition testing is less work for more payoff. I agree with that.
      But, it seems they're assuming that the randomly chosen test values are
      hand-coded once and used just like unit tests thereafter.

      With QuickCheck, I define a data generator, and I get as many tests as I want.
      I use the standard configuration, 100 tests for each property on every run.
      I do a test run roughly every five minutes. (I like HourglassProgramming.)
      I don't think it would be cost effective to write a statistically equal number
      of tests with partition testing.

      Purely generative testing can keep you from easily testing corner cases that
      you think of while you're coding. QuickCheck doesn't allow you to directly
      specify test values. I think I can add that feature, though not this week.

      Writing a decent generator is important. If you write a custom data value
      generator that doesn't cover all the test values, you could miss bugs.

      > One of the big advantages of partition testing is that it helps with
      > the design. Random testing is no help in test-first design.

      I disagree, but I'm listening.
      In what ways does partition testing help such that generative testing doesn't?

      Ways that I benefit from tests are:
      The code is done when the tests succeed.
      My refactoring is sound if the tests succeed.
      My new code is sound if the previously failing tests succeed.
      New code has to immediately focus on 'how to use', so I think more about API.
      If a new test doesn't fail, something's wrong with the test, or I already wrote
      that functionality, time to investigate.

      I think all of these would work fine with both single-case testing and
      generative testing. As mentioned above, the inability to specify a test value
      directly is a drawback if you already have a corner case in mind.

      > How much of this is your skill vs. language choice? If you were to
      > have a "shootout" with a company that does, say, Perl, and your company
      > that does, say, Python, which would win?

      That's hard to measure. It would depend on the task mostly.
      For many tasks I'd rather use Haskell, of course :-)

      > I believe there is a simple test. How easily can your partners take
      > over your code and vice-versa?

      Good question. My only business partner at the moment is my fiancée.
      She's not really interested in programming, though she does edit existing code.
      My code in open source projects is taken over just fine by others.
      I'm not sure if that counts.

      > Aesthetics are not the same as readability. Literature is about
      > aesthetics. Readability means a peer can read your code as easily as
      > their own.

      That's a good point, I have been conflating those two.
      --
      Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
      It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson
    • Show all 58 messages in this topic