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.
  • The sample sizes were far too small to draw any reasonable conclusion.

    I don't think you're going to find much "evidence" unless there are large scale studies of complex projects. (Which have their own issues as you don't have good controls). This is the reason why much of "social science" isn't really science.

    Speaking personally and anecdotally, however, my hypothesis is that the reported "effectiveness" of TDD is driven largely by two factors: (a) it promotes a well-articulated description of expectation

    • When I am writing several tests first I do think it's sort of in the spirit of TDD but purists might take exception. One extreme TDD exercise [gojko.net] I read about sounded very frustrating for the participant, but the person coordinating the exercise responded in the comments that he wouldn't use the "one test, one bit of code, repeat" style every time, so I'm glad that he's not over zealous about it.

      Still, I often find myself writing quite a bit of code and then coming back and writing the tests. The times I usually get bitten by this have been when the code authors go crazy on inheritance and I've accidentally overridden an inherited method. That's very frustrating to track down (in fact, I wasted a lot time on this last week when this happened twice). I should at least write the can_ok $object, $method tests first.

      On that latter note, perhaps it would be nice if we could mark methods as "final" and throw an exception if they're overridden. Or perhaps mark a method as overriding something. Hmm ... how would I implement that? I see problems with that approach because sometimes you really do need to override something. I wonder about this?

      use Attribute::Override;

      use parent 'Some::Class';

      sub foo : override { ... } # fails if it doesn't override
      sub bar { ... }            # fails if it does override

      The problem with this would be that traversing the inheritance hierarchy can be slow, buggy (AUTOLOAD, anyone?), and thus not suitable for production, but perhaps it could only trigger if $ENV{HARNESS_ACTIVE} is true?

      It also would serve as very handy documentation because you could see at a glance if you've overridden something or not.

      • On the "purists" comment -- it could be the normal difference between the teaching environment and the real world. In the teaching environment, the importance of "proper" process tends to get exaggerated. In the real world, with experience, we take shortcuts.

        On API testing -- I've often done "can_ok" either for a class or else for "main" to confirm automatic exports. What I've never really done (well) is confirm that no other methods exist. I might need to look into Class::Sniff or related techniques fo

      • Your idea for detecting accidental overrides seems overly complex. How about just comparing what is meant to be overridden to what Class::Sniff->overridden says has been.
        • Class::Sniff is too heavy weight for this. It also captures code at a snapshot in time. It doesn't tell me if the method cache is invalidated (MRO::Compat will let me do this with mro::get_pgk_gen).