Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: Programming is combat

by brian_d_foy (Abbot)
on Jul 08, 2004 at 17:24 UTC ( #372869=note: print w/ replies, xml ) Need Help??


in reply to Re: Programming is combat
in thread Programming is combat

Oh, no one is going to buy the book. I starting collecting these sorts of books because they show up on the remaindered racks at book stores. This is only a fantasy of mine because it would suck away a lot of free time and get me nothing that I could use to pay rent.

For me, "train as you fight" shows up mostly as a t directory. When I am good about this (and I am not always that good), I at least create tests to ensure the code compiles and the pod is valid. When I get over that little hump, adding other tests is easy: I already have the t directory and am using "make test".

--
brian d foy <bdfoy@cpan.org>


Comment on Re^2: Programming is combat
Re^3: Programming is combat
by BrowserUk (Pope) on Jul 08, 2004 at 17:50 UTC

    I'm still to be, and don't expect to be, convinced of the value of \t directory and Test:* modules.

    Don't misread that. I'm strong on tests and testing. It is the only tool short of suck-it-and-see that we yet have for trying to establish the quality of the code we produce.

    The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code. You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

    In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

    Design by contract shows great potential (IMO). I had hoped that something similar would be integral to P6, but I haven't seen any signs of it. I'm hoping that the (proper) macro facility will allow this to be added in fairly short shrift after the fact. Time will tell.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      DBC is integral to Perl 6. If you google for "design by contract apocalypse perl", you'll discover that it's even been mentioned in discussions here on PM.

        Indeed. Sorry for having disseminated FUD. My only defense is that it had been a while since I read Apo4 and I had forgotten about PRE and POST blocks.

        One question that I couldn't answer from my (quick) reappraisal of Apo4. Is there any intent that PRE & POST blocks will be "turn-offable" (with apologies to the BG ads) via command line switch or other similar mechanism?


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
        DBC is integral to Perl 6

        Since the subject's come up ;-)

        PRE and POST will obviously handle pre-/post-conditions for methods. However - I've not spotted an easy way of expressing class invariants. Is there something that I've missed?

        Also, there do not appear be a built ins for dealing with naming conflicts as there are in languages like Eiffel. How would I rename method foo() to bar() in a sub-class and keep the pre- and post-conditions?

        Disclaimer: I've still not read A12 properly, so apologies if the answer is in there and I missed it when I skimmed it :-)

      The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code

      Test::Inline?

      You also might find the idea of Zero Button Testing appealing.

      Personally, I find having the code and the tests in the same document gets in the way of reading the code and interferes with refactoring, but YMMV.

      You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

      Doctor, it hurts when I do that :-)

      In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

      I see people asking for this sort of functionality a lot and it confuses me. I must be misunderstanding what you mean since, on the face of it, what you're requesting seems to be impossible. How would the magic test producer know what the code should do.

      Design by contract shows great potential (IMO)

      Interestingly enough DBC used to be my preferred design methodology, before I discovered TDD (Eiffel is still one of my favourite languages). Because you're dealing with concrete data rather than an abstract contract I find it much easier to incrementally develop code with tests.

        Donít forget specification-based testing ŗ la tmoertelís Test::LectroTest (which he talked about in RFC: Tutorial on Testing). Iíve tinkered with it some; when it fits the kind of unit being tested, itís spectacular.

        Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://372869]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2014-09-02 19:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (29 votes), past polls