Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: A danger of test driven development.

by jmcnamara (Monsignor)
on Oct 03, 2005 at 12:01 UTC ( #496881=note: print w/replies, xml ) Need Help??


in reply to A danger of test driven development.


I find that test driven design give a genuine boost to my productivity. However, your post touches upon a minor worry that I have about it.

I think that with test driven design it is possible to write code to pass tests rather than code that fulfils the intended purpose. The presence of a safety net may make you a little careless on the high-wire.

I'd still strongly advocate test driven design but I think that it is worth remembering that code is written for a purpose and that purpose isn't to pass tests.

--
John.

  • Comment on Re: A danger of test driven development.

Replies are listed 'Best First'.
Re^2: A danger of test driven development.
by adrianh (Chancellor) on Oct 03, 2005 at 13:30 UTC
    I think that with test driven design it is possible to write code to pass tests rather than code that fulfils the intended purpose. The presence of a safety net may make you a little careless on the high-wire.

    Yeah, I see that sometimes. It often comes from people thinking they're finished when all the tests pass, rather than when they can't write a failing test.

Re^2: A danger of test driven development.
by xdg (Monsignor) on Oct 03, 2005 at 20:44 UTC
    I think that with test driven design it is possible to write code to pass tests rather than code that fulfils the intended purpose.

    But how does one verify the intended purpose? How does one ensure that the code fulfils that purpose? How does one ensure that later changes to fulfil some other purpose don't interfere with purposes already satisfied?

    The idea behind TDD is that the tests become the only real specification that matters because they are the only ones that are written formally at the level of code. Yes, it's possible to mis-write a test. It's also possible to mis-write code. Nothing can prevent one from mis-interpreting a poorly-written (or even a well-written) specification from time to time.

    That said, good test technique should focus on "black-box" testing -- abstracting implementation away and reducing tests to inputs and outputs that can be mapped to requirements. Given some interaction or input, the code produces some result or output. It's harder (though not impossible) to get that wrong. Also, the process of writing tests reveals weaknesses or lack of clarity in the requirements that might otherwise be missed.

    TDD isn't a game for getting tests to pass; test coverage of 100% doesn't prove correctness. But TDD shifts the burden of proof from the developer to the test-writer, who has responsibility for translating user requirements into a verifiable specification (the test) with fidelity. And isn't poor requirements one of the things we hate? TDD reveals that up front, before the coding is done, instead of after when efforts wind up wasted.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2019-12-06 19:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (157 votes). Check out past polls.

    Notices?