Hi Kaleb,
Do you strictly follow the three laws of TDD as literally written?
No, but when I get into trouble, I stop, back up and get more precise
about how I'm proceeding.
What step size do you typically have when going back and forth between tests and code?
There should be no "typical" step size in your practice. Beck stressed
the importance of learning
to "shift gears" - to go at various speeds based on your needs at the
moment. Sometimes you can
move ahead successfully in big steps, sometimes you need to go slower.
Practice both.
Imagine if you decide to always move at a certain speed, without
regard to the terrain. Either you
would be moving at a ridiculously slow pace on the sidewalk or running
down rocky hillsides. Either
one could get you in trouble.
How do you decide the appropriate step size?
A combination of what I'm doing - is it similar to something I've done
before for example - and
how I'm doing - how well are things moving along. When I go too fast -
too big steps - things start
to feel uncomfortable and I slow down.
When writing a test, do you define a method or constructor with all its expected parameters?
I define it with the parameters I know of and have available a the
moment. Code is really easy to
change and there's no reason to put everything in when I don't yet
know for sure what I need or
where I will get the parameters.
Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?
No. Except in the sense that any test could be wrong. A test tests
what it tests. You have to
be aware of what you are testing and what you have not yet tested. No
single test is "complete"
in any meaninful sense of the word.
Charlie
