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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Nagler
    ... Random testing is very useful. And, data generators are useful when the data values are not that important. Most of the stuff I test seems too complex for
    Message 1 of 58 , Apr 4, 2005
    • 0 Attachment
      Shae Matijs Erisson writes:
      > QuickCheck doesn't allow you to directly
      > specify test values. I think I can add that feature, though not this week.

      Random testing is very useful. And, data generators are useful when
      the data values are not that important.

      Most of the stuff I test seems too complex for generators. For
      example, if I am testing a sendmail API, I need to test the "." on a
      line case. If I don't, it might break. Another example is invalid
      email addresses. The API might want to throw an exception if the
      address is invalid. How does random testing help here? The code
      which tests email address validity has already been unit-tested. I
      just want to make sure that if I put in one invalid email, the
      API does the right thing.

      > In what ways does partition testing help such that generative
      > testing doesn't?

      In test-first programming, I can define one case, and it will fail. I
      don't need to generate 100 cases, since no code is written at first.
      Then as the implementation is fleshed out, I may have to stub out
      values. Again, the data generator for is too complex.

      As I mention in my book, a unit test serves as API documentation in
      XP. Each case should document a corner case (boundary condition) of
      an equivalence class. I expect to see the boundary conditions listed
      in the test.

      Also, by choosing appropriate test data, I am forced to think through
      the algorithm. In the test below, I had to reverse engineer the
      exponentional moving average equation to get nice values for the first
      test case group (EMA length 4). By doing this, I get insight into the
      algorithm.

      Hopefully, this test is self-documenting to y'all:

      use strict;
      use Bivio::Test;
      Bivio::Test->new('Bivio::Math::EMA')->unit([
      4 => [
      compute => [
      5 => 5,
      5 => 5,
      10 => 7,
      ],
      value => 7,
      ],
      'Bivio::Math::EMA' => [
      new => [
      -2 => Bivio::DieCode->DIE,
      0 => Bivio::DieCode->DIE,
      1 => undef,
      2.5 => Bivio::DieCode->DIE,
      ],
      ],
      50 => [
      value => Bivio::DieCode->DIE,
      ],
      ]);

      (Apologies to people who don't recognize this code. This was the
      original version before it was forced into imperative form by the
      reviewers. I probably should change it back, but I need to finish the
      Logistics chapter first.)

      If am looking at financial contract checking software, I would argue
      that you simply have to do partition testing. You are going to find
      defects, and they will have to be regression tested. These individual
      cases swamp the random test code.

      > My code in open source projects is taken over just fine by others.
      > I'm not sure if that counts.

      It does, imo. I also believe that someone who writes as eloquently as
      you do in (what I am assuming is) your non-native language, probably
      also writes easy to read code.

      What I believe is most important is "impedance matching" of
      experience. The above test is an impedance mismatch with CPAN or
      any of the xUnit APIs.

      That's why I believe culture is so much more important than language.
      If you work at bivio, you "pretty much" know how to read the above
      code. If you understand DSLs, you'll see this as one, and possibly
      appreciate the abstraction. If you a Perl programmer who happens to
      be reading this list, you might find the above test quite bizarre.
      However, it might pique your curiosity to learn more, which might lead
      to thinking differently without changing languages. It's not as far
      to leap, and it's something you might be able to put into practice
      tomorrow or the next day.

      Well, this message is far too long. Long live the global conspiracy!

      Rob
    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
      • 0 Attachment
        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 ...

        :c)

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