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

Re: [extremeperl] Declarative Testing

Expand Messages
  • Rob Nagler
    ... That is an interesting point, and one I have struggle with for some time. There s also the class name duplication EMA . The name of any thing in bOP is
    Message 1 of 8 , Aug 31, 2005
      Curtis Poe writes:
      > Despite the complaints that Adrian Howard's code had a lot of
      > duplication, the Bivio code still had duplication in the call to
      > Bivio::DieCode->DIE.

      That is an interesting point, and one I have struggle with for some
      time. There's also the class name duplication "EMA". The name of any
      thing in bOP is the file in which it resides (class) and its entry
      point (sub). We don't export variables except in one case
      (Bivio::IO::Trace). The name Bivio::DieCode->DIE is *long*, but it
      does not duplicate the concept it implements.

      I believe you didn't make as big of a deal about the duplicate EMA,
      because it is short. Bivio::Test is repeated, and so is use strict.
      I have considered dropping both as we have done in our acceptance
      infrastructure, which provides an excellent extension mechanism with
      short names. Here's how I might refactor it:

      [
      EMA => [
      new => [
      -2 => DIE(),
      0 => DIE(),
      2.5 => DIE(),
      1 => undef,
      ],
      ],
      ];

      These could be "bunit" files, just like our acceptance tests (which
      require and interpreter to run) are called "btest". Something I may
      get around to.


      > use Bivio::Test;
      > Bivio::Test->new('EMA')->unit([
      > # is the duplicate "EMA" necessary?
      > EMA => [
      > new => [
      > [ -2, 0, 2.5 ] => Bivio::DieCode->DIE,
      > 1 => undef,
      > ],
      > ],
      > ]);

      There's a problem with this refactoring. The non-shortcut syntax for
      a method's input is:

      [1] => undef,

      This means pass a single argument to the method, and ignore the return
      result. Since single argument methods are common in bOP, the
      shorthand is this:

      1 => undef,

      It's syntactic sugar, which removes clutter. However if EMA took
      another argument, it would have to be in brackets:

      [1, 'other arg'] => undef,

      Here's how I would refactor it to remove the duplication of DIE:

      EMA => [
      new => [
      map(($_ => Bivio::DieCode->DIE), -2, 0, 2.5),
      1 => undef,
      ],
      ],

      While this removes the duplication, it introduces a new concept
      (different inputs yielding the same result). We often use map, but I
      wrote this test in the spirit of "one line per case". That's "good
      enough" for me, and it does serve as excellent documentation. OTOH,
      you are absolutely correct that it requires unnecessary duplication.

      > Given that most are unlikely to use Bivio, perhaps someone can propose
      > a Test::Declare framework using Perl's standard testing tools? What
      > would the syntax be?

      Talk about NIH. ;-) I would expect that you would find that any
      serious attempt at Test::Declarative would run into the same problems
      that Bivio::Test has: abstractions are difficult to understand.
      However, the more the merrier. :-)

      Rob
    • Curtis Poe
      ... Possibly, but it s fair to point out that if a company has an established, working code base, switching to Bivio may not be cost effective (of course, I ve
      Message 2 of 8 , Sep 1, 2005
        On Aug 31, 2005, at 4:28 PM, Rob Nagler wrote:
        > > Given that most are unlikely to use Bivio, perhaps someone can
        > propose
        > > a Test::Declare framework using Perl's standard testing tools?  What
        > > would the syntax be?
        >
        > Talk about NIH. ;-)

        Possibly, but it's fair to point out that if a company has an
        established, working code base, switching to Bivio may not be cost
        effective (of course, I've no idea what Bivio does, either).

        >  I would expect that you would find that any
        > serious attempt at Test::Declarative would run into the same problems
        > that Bivio::Test has: abstractions are difficult to understand.
        > However, the more the merrier. :-)

        Yeah, that's true. Still, it would be an interesting experiment.

        Cheers,
        Ovid
      • Terrence Brannon
        I interviewed with the director of a small team here in Los Angeles yesterday. The guy was part of an Extreme Programming outfit in Arizona. He said that
        Message 3 of 8 , Sep 1, 2005
          I interviewed with the director of a small team here in Los Angeles
          yesterday. The guy was part of an Extreme Programming outfit in
          Arizona. He said that Extreme Programming came from GM and Ford motor
          company where they weren't trying to be first to market.

          He also said that while XP is good in general when you are trying to
          beat everyone to market, it is impractical: they could have been a
          year ahead of everyone but instead were a year behind.

          Any feedback on this?

          --
          Carter's Compass: I know I'm on the right track when,
          by deleting something, I'm adding functionality.
        • Rob Kinyon
          ... Personally, I feel that XP means you re *quicker* to market because you re only implementing those features you re selling right now. In addition, you re
          Message 4 of 8 , Sep 1, 2005
            On 9/1/05, Terrence Brannon <bauhaus@...> wrote:
            >
            >
            > I interviewed with the director of a small team here in Los Angeles
            > yesterday. The guy was part of an Extreme Programming outfit in
            > Arizona. He said that Extreme Programming came from GM and Ford motor
            > company where they weren't trying to be first to market.
            >
            > He also said that while XP is good in general when you are trying to
            > beat everyone to market, it is impractical: they could have been a
            > year ahead of everyone but instead were a year behind.
            >
            > Any feedback on this?


            Personally, I feel that XP means you're *quicker* to market because you're
            only implementing those features you're selling right now. In addition,
            you're quicker to market with new features and bugfixes. I'm a little
            confused as to where the person in question got his/her information.

            Rob


            [Non-text portions of this message have been removed]
          • alex_viggio@comcast.net
            I d doublecheck where this director gets his facts (did he work with Catbert?) and what rigorous development process he sees as faster to market than XP, other
            Message 5 of 8 , Sep 1, 2005
              I'd doublecheck where this director gets his facts (did he work with
              Catbert?) and what rigorous development process he sees as faster to
              market than XP, other than "seat of your pants prototyping with every
              sincere intention to properly implement the v3.0 release."

              See http://www.xprogramming.com/publications/dc9810cs.pdf for a case
              study on the Chrysler project commonly described as the genesis of XP.
              At least his source got the vertical market right :)

              This is posted on Ron Jeffries' site, one of the members of the project
              team and a true Dilbert in a sea of Wally programmers.

              - Alex

              Terrence Brannon wrote:

              >I interviewed with the director of a small team here in Los Angeles
              >yesterday. The guy was part of an Extreme Programming outfit in
              >Arizona. He said that Extreme Programming came from GM and Ford motor
              >company where they weren't trying to be first to market.
              >
              >He also said that while XP is good in general when you are trying to
              >beat everyone to market, it is impractical: they could have been a
              >year ahead of everyone but instead were a year behind.
              >
              >Any feedback on this?
              >
              >
              >
            • Curtis Poe
              ... I d like to see a company that truly uses XP. Most of the time, I see companies adopt little bits and pieces but many of those pieces are tightly coupled
              Message 6 of 8 , Sep 1, 2005
                On Sep 1, 2005, at 8:20 AM, Terrence Brannon wrote:

                > He also said that while XP is good in general when you are trying to
                > beat everyone to market, it is impractical:  they could have been a
                > year ahead of everyone but instead were a year behind.

                I'd like to see a company that truly uses XP. Most of the time, I see
                companies adopt little bits and pieces but many of those pieces are
                tightly coupled with other pieces and adopting them "halfway" only gets
                part of the benefit.

                For example, in iteration planning meetings where programmers are
                picking up story cards, if you don't have a customer-driven process to
                assign priorities and customer feedback on what's already done, you
                wind up guessing what needs to be done and only find out later you've
                guessed wrong. Additionally, with XP, by having customers review the
                process every iteration, you find out *now* what needs to be changed.
                That's a lot less expensive and time-consuming than finding out a few
                months down the road.

                So far on the XP-driven projects I've been on development is much
                faster. I've spent much less time in the "oh crap, we're screwed"
                meetings.

                Cheers,
                Ovid

                [Non-text portions of this message have been removed]
              • Adam Turoff
                ... Sounds like in the absence of hard data, it s pretty easy to fabricate enough annecdotal evidence to back up your chosen point of view. -- Adam
                Message 7 of 8 , Sep 3, 2005
                  On 9/1/05, Terrence Brannon <bauhaus@...> wrote:
                  > He also said that while XP is good in general when you are trying to
                  > beat everyone to market, it is impractical: they could have been a
                  > year ahead of everyone but instead were a year behind.
                  >
                  > Any feedback on this?

                  Sounds like in the absence of hard data, it's pretty easy to fabricate
                  enough annecdotal evidence to back up your chosen point of view.

                  -- Adam
                Your message has been successfully submitted and would be delivered to recipients shortly.