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

Declarative Testing

Expand Messages
  • Curtis Poe
    ... You know, I really think this is interesting when you compare it to ... Despite the complaints that Adrian Howard s code had a lot of duplication, the
    Message 1 of 8 , Aug 31, 2005
    View Source
    • 0 Attachment
      Rob Nagler wrote:

      >in Bivio::Test this would be:
      >
      >    use strict;
      >    use Bivio::Test;
      >    Bivio::Test->new('EMA')->unit([
      >      EMA => [
      >          new => [
      >            -2 => Bivio::DieCode->DIE,
      >            0 => Bivio::DieCode->DIE,
      >            1 => undef,
      >            2.5 => Bivio::DieCode->DIE,
      >          ],
      >      ],
      >    ]);

      You know, I really think this is interesting when you compare it to
      another email:

      > > #! /usr/bin/perl
      > >
      > > use strict;
      > > use warnings;
      > > use Our::Test::HTML::HouseStyle qw( style_ok );
      > > use Our::Test::Config qw( html_files );
      > > use Our::Test::Utils qw( test_all );
      > >
      > > test_all { style_ok( $_ ) } html_files();
      >
      > Note the redundancies.  test_all x 2, style_ok x 2, and test_all x 2;
      > qw() is twice. 

      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. but I'm still curious about the declarative
      nature of the code. I could see refactoring the Bivio to this:

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

      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?

      Cheers,
      Ovid
    • 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 2 of 8 , Aug 31, 2005
      View Source
      • 0 Attachment
        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 3 of 8 , Sep 1, 2005
        View Source
        • 0 Attachment
          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 4 of 8 , Sep 1, 2005
          View Source
          • 0 Attachment
            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 5 of 8 , Sep 1, 2005
            View Source
            • 0 Attachment
              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 6 of 8 , Sep 1, 2005
              View Source
              • 0 Attachment
                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 7 of 8 , Sep 1, 2005
                View Source
                • 0 Attachment
                  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 8 of 8 , Sep 3, 2005
                  View Source
                  • 0 Attachment
                    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.