Jacinta Richardson wrote:
Benno wrote:
[EMAIL PROTECTED] wrote:
Make it RUN;
Make it RIGHT;
Make it FAST; and
Make it NICE.
I think the idea that the TDD guys are putting forward is that "Make it NICE" (e.g:
automated test suite), means that you can make it "RIGHT" and "FAST" with less effort
than if you didn't have an automated test suite.
I think it may actually be a slightly different mind-set than just making code
"nice". I think the TDD people have the argument that tests help so much in
ensuring it "run"s that they're an essential part of that step. We all do
testing on the code we develop, it's just that *most* of us are testing for the
common case (it works) and some obvious broken cases (it fails) with throw-away
tests. TDD formalises those tests, then because we don't have to spend so much
time regenerating the same informal tests, we can spend a little extra time
putting in test cases for wierd edge cases, thus helping the code we're writing
to "run" better.
Making it RIGHT (comparing it to the spec -- black box testing), FAST
(performance testing) and NICE (documentation/interface testing) may or may not
be easier following TDD, but it shouldn't be any harder.
A little more detail if it helps.
1. Start of Development
\/
2. Make/Modify Specs/Tests<<<
\/ ^
3. Code and Run Test >>>>> ^ If test fails. (Make it RUN)
\/ If pass test ^
4. Code and Right Test >>>>>^ If test fails. (Make it RIGHT)
\/ If pass test. ^
5. Code and Fast Test >>>>>>^ If test fails. (Make it FAST)
\/ If pass test. ^
6. Code and Nice Test >>>>>>^ If test fails. (Make it NICE)
\/ If pass test.
7. End of Development.
Cheerio,
O Plameras
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
