Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Re: What efforts go into a programming project? (Somewhat OT)

by echo (Pilgrim)
on Aug 10, 2001 at 20:10 UTC ( [id://103931]=note: print w/replies, xml ) Need Help??


in reply to Re: What efforts go into a programming project? (Somewhat OT)
in thread What efforts go into a programming project? (Somewhat OT)

you build the test code first, and then design/code until the tests pass

I've tried that and found it didn't work out all that well. In order to write a sensible test, the feature more or less has to be completely designed. I found myself ping-ponging between the code and the test as I was refining the design. My experience is that test suites can't really be written efficiently until a significant amount of design and coding has been done.
Otherwise I agree with you, automated test suites are the way to go.

Replies are listed 'Best First'.
Re: Re: Re: What efforts go into a programming project? (Somewhat OT)
by apsyrtes (Beadle) on Aug 11, 2001 at 02:15 UTC
    My take on this testing thing is that XP promotes one level of design (project design) while programmers take it to mean a different level (code design.)

    When it is mentioned "design the tests first" - these are tests on the level of "how will we determine that the code satisfies requirement X" not "this algorithm keeps pumping out numbers that are off by 1/100... I better run the debugger and find out what's going on."

    Project design tests should be written first. Users and Programmers do not view requirements in the same light, so when they try and speak requirements in the same language, projects fail. Designing project-level tests first forces the Users to properly define their requirements and then forces the Programmers to translate that effectively in terms that they understand - the Users have their requirements and the Programmers have their tests - both are looking at the exact same thing in their own language.

    This way, the Code Design will be driven by the tests - i.e. the actual requirements, rather than what the Programmers think the requirements are. At the same time, the Users know what results they can expect, and can compare this with what they want and be satisfied that all is well. This results in projects that are done right the first time.

    Code design level tests must necessarily be designed/run at design/coding time - this is also the kind of testing that first jumps into programmers heads when they read about XP, and is, IMHO, why this aspect of XP is so often taken to task.



    ---Apsyrtes
Re: Re: Re: What efforts go into a programming project? (Somewhat OT)
by Anonymous Monk on Aug 13, 2001 at 04:30 UTC
    I've tried that and found it didn't work out all that well. In order to write a sensible test, the feature more or less has to be completely designed.

    That's the point. :)

    You have a feature you want to write. Instead of asking yourself "How can I get my code to do this?", you ask yourself "How can I write a test that proves my code can't do this?" In the process of writing that test, you will discover the design of the code that will make the test succeed. This is the Zen beauty of test-first design. Then you add more tests until you can no longer think of ways to break what you've written.

    This ensures that you don't do too much work. So long as you only test those things you need, and you don't write anything that isn't contributing to making a test pass, you're not over-designing, or succumbing to bloat.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2024-03-28 10:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found