Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^4: Programming is combat

by adrianh (Chancellor)
on Jul 09, 2004 at 16:42 UTC ( #373191=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^4: Programming is combat
Re^5: Programming is combat
by Aristotle (Chancellor) on Jan 15, 2005 at 02:18 UTC

    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.

      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.

      I agree that it's is useful stuff where it fits, but to be honest I don't find it fitting that often :-)

      The trouble I have applying specification based testing is that, like design by contract, it's tricky to apply incrementally. Personally I find TDD and specification based tests a bad fit since I now code in small increments, and specification based tests are very much all-or-nothing.

      Specification based tests are certainly a useful tool, but I don't find myself reaching for it very often.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (14)
As of 2014-10-21 18:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (106 votes), past polls