Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Something that is lost in the caricature is that by Test::Most::explain() wrapping up output and dumping you can not use explain() to output as part of a normal failure. I like to do this:

    is_deeply $have, $want or diag explain $have;

    Test::Most thinks the opposite use case is important, it's the equivalent of "note explain". If you read the docs for explain() in Test::More and Test::Most it's pretty clear we have different ideas about how it's to be used. I could have just decided which one the user gets to do, and screwed the rest, but I err on the side of flexibility.

    It's worth noting that Test::More::explain() is hard wired to "prove -v" so not only does it make you rerun the test to get your diagnostics (which makes heisenbugs difficult to track), but you have to be running it through prove. prove and I are not joined at the hip, but since that's how most users do it I guess that's ok. Oh, and if you want to archive your test results you don't get the extra output unless you remembered to run it in verbose mode... through prove. But most people don't archive test results so I guess that's ok, too.

    And really, it's five characters. A place in Pittsburgh I worked had a saying: "Just because you drive to Ohio doesn't mean you're going to California". Put another way, it's the Ben & Jerry's fallacy. That being since eating too much ice cream is bad for you, eating one scoop of ice cream is bad for you and you should never eat ice cream.

    Looking at it another way, Ovid has declared a Domino Theory [wikimedia.org] of Design. That one step towards Java will lead the surrounding code becoming more Java-like and so on until you're supporting Central American dictators and involved in two land wars in Asia. I mean... until half a year after the decision was made you're still arguing over five characters. :P

    Speaking of reductio ad Java, oddly enough yes, that is basically the way Test::More is going and for basically the right reasons. But it is doing it *internally*, at the Test::Builder level and below what the user normally sees. A good interface is not just flexible, but knows when and how much flexibility to show. Java falls flat on it's face by giving you all the flexibility all the time. Equivalent to one of those monster all-in-one remote controls.

    As an aside, I remember a year or two ago when Java programmers discovered that inside of having to create and pass in all the delegate objects to a constructor, the constructor could make the for you! And the they gave it some fancy name and declared that nobody else but Java had it. In short, they discovered this:

        sub new {
            my($class, %args) = @_;
     
            # Wow, we can initialize objects for you!
            $args{buffer}  ||= Some::Buffer->new;
            $args{storage} ||= Some::Storage->new;
     
            return bless \%args, $class;
        }

    But I digress. A lot.

    Deciding what diagnostic information to display to the user and when is a test by test choice, so it's part of the user visible Test::More interface. Deciding what filehandle to output to and what format to output is a choice that effects the whole test suite. It's a choice to be made once and so is pushed down to the Test::Builder level, out of the user's way but available.

    The increased flexibility will allow you can flip a few switches and have all your testing modules start outputting XML or POSIX or nothing (oft requested so you can use testing functions as normal comparison functions) instead of TAP.

    In the end, I point all this out as much because I get a kick out of needling Ovid as to show that Test::More and Test::Most have different design philosophies and that's just fine. It's all working as designed. We don't have to agree on the One True Way because there is none. Different modules addressing different use cases but all working together and all benefiting from the flexibility built into the system.

    • You're absolutely right that my solution is not as flexible. But ...

      Years ago I worked at a company where we made revenue projections for a particular industry. Industry executives could log on and when they saw what they were trying to project, they had a "weighting" factor that they could enter and the numbers would be adjusted with that. For the sake of argument, we'll say that number defaulted to 12, but based on the executive's knowledge of what they were offering, they would adjust that up or down.

      • Yes, inertia driving design is bad. What does it have to do with this?

        • The vice president argued for a suboptimal solution because that's how things are now. Though I've got other reasons for wanting explain() to function the way it does, part of the reason to keep it the same is because that's how things are now.

          • I think it's the "But..." that made me think it was an accusation that Test::More's explain() is the result of Design by Inertia... which doesn't make any sense since Test::More can't "do it the way it was always done" for something that didn't exist. Design by Inertia would have been to do what Test::Most does.

            Are you considering changing explain() in Test::Most?

            • I wasn't planning on changing explain() in Test::Most. From what I can tell, it's now used widely enough that I'm not keen on breaking backwards-compatibility without a strong reason.

      • PS That was at R*****k, right?

      • I had a job like that. A huge commericial real estate company wanted to have all sorts of fancy graphs about prices and market conditions, but they didn't know how to do it themselves.

        It turns out prices had nothing to do with the market. They just increased monotonically. They lost interest in showing customers market data after that.

        In that case, I'd change the number back to 12, but insert a +3 somewhere else. :)