No Time for Testing
-
I get the feeling that some people do not understand TDD (I do not understand many things here and elsewhere so this is no claim of superiority).
Tests for TDD are in no way acceptance tests. The testing as part of TDD is unit testing. It doesn't matter if requirements changes or even if you are guessing them. If you think you you can start writing code then you can start writing tests. As soon as you are ready to codify a thought then you can codify the test. The tests capture the requirements at that point in time. If the requirements change (or even turn up, right?) then you change the tests, the code fails and you fix the code. This even/especially works for refactoring code.
TDD is simply about making you think about what you want to achieve and capturing that in a test BEFORE you attempt to achieve it. The reason behind this is that we all tend to write tests that pass but writing them before (knowing that they will fail as nothing has been implemented) removes that unintended bias.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
In honor of this article being republished...
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Viewing 2 posts - 31 through 31 (of 31 total)
You must be logged in to reply to this topic. Login to reply