Test driven development

[A.T.Hofkamp]

On 2008-01-24, ajcppmod at gmail.com <ajcppmod at gmail.com> wrote:
> I like the concept of TDD but find it difficult to put into practice
> most of the time. I think this primarily because I tend to like top-
> down development and functional/object decomposition and TDD feels
> more like a bottom-up approach.

It is not bottom-up imho.
The main difference imho is in abstract, far-away goals versus running code for
a small concrete sub-set of functionality in the short-term.

How you provide that "running code for a small concrete sub-set of
functionality in the short-term" is not defined by the approach.

> So my question is when approaching a project that you want to employ
> test driven development on how and where do you start? And also if

1. Define a small step of extended functionality that you can finish by the
   end of the week.
2. Write tests that should run after implementing the functionality.
3. Write code that make the tests work.
4. goto 1.

> anyone uses top-down design with TDD I would be interested in how you
> do it (does it involve lots of mock objects/ is the first test you
> write the last one to pass)?

No, with TTD there is only one goal, namely increasing the percentage of passed
tests to 100%.
(which you then break again by doing steps 1 and 2, and fix again in step 3)


TTD is about DESIGNing for WHAT YOU NEED TODAY, not for what you might need
tomorrow.

You may want to do a small top-down design (and next week another slightly
larger one, and another slightly larger one in 2 weeks, etc), but you should
NOT DESIGN FOR MORE FUNCTIONALITY THAN WHAT YOU NEED for all tests to pass.


Sincerely,
Albert

PS The above is purely from a TTD perspective.

   I personally do not really think you can SOLVE ALL PROBLEMS in the most
   efficient way using TTD. On the other hand, the concrete, short-term
   approach does produce running code fast for the implemented sub-set of
   functionality, which may be nice in a project.