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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Nagler
    ... 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
    Message 1 of 58 , Mar 31, 2005
      Shae Matijs Erisson writes:
      > In my opinion, this sort of generative testing is a better approach that single
      > case unit testing. It can require more work to get the more general testing.
      > I bet you're not surprised.

      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:


      I think the type of test methodology depends on the problem and the
      programming language. For example, for C programs, I like random
      testing, because there are so many subtle ways to screw up. For Perl,
      I prefer partition testing. I tend to think about problems in terms
      of examples, and those examples end up being test cases.

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

      > QuickCheck has been ported to Common Lisp, Python, Perl.
      > The ports do lose something in the process, for a variety of reasons.

      So has xUnit, but is merely being popular. PG thinks there's little
      value in being popluar.

      > > What do you mean by "better job"? Done faster? Higher quality?
      > Done faster, higher quality, and more 'code as communication'. Want details?

      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?

      > http://lists.alioth.debian.org/pipermail/shootout-list/2005-March/001296.html

      Here's a quote from the above:

      > The problem I see is that it's easy to directly test LOC, CPU time,
      > RAM usage, but it's really hard to test readability and good use of
      > idioms. At some level that's like unit testing poetry.

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

      > I would really like to know. Maybe there's already such a thing for Perl?

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

    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
        Greg C wrote:

        > Consider: projects A and B have identical goals. In project A, you
        > have free
        > rein in your choice of software and hardware tools. However, the
        > manager sets
        > arbitrary deadlines, likes to stand behind people and criticize their
        > code as
        > they type,

        Wait. That sounds like Rob ....
        ;c) (kidding)

        > On project B, the choice of langauge and hardware are made for you and
        > there's
        > only one computer per two programmers. On the other hand, the manager
        > sees his
        > people as people, negotiates requirements and schedules on a realistic
        > basis,
        > trusts his people, follows a set of best practices (be it XP or some
        > other) and
        > chases everyone out of the office at 5:30.

        Wait. That *also* sounds like Rob ...


        (not kidding!)
      Your message has been successfully submitted and would be delivered to recipients shortly.