Re: TDD for numerical algorithms

That's a nice distinction, and I would put it similarly. It is a form
of Test First, but it is not TDD.

I have done that before, but it is not usual for me. I generally
ignore algorithm design preferring to focus on the business problem
exclusively until I have some performance need that compels me to
optimize. Then I would use a profiler to find bottlenecks, write some
performance tests around those bottlenecks, and optimize them until
the performance tests passed consistently.

The interesting thing is that when I keep the design simple I rarely
have to go there, because I rarely find myself with a too slow app to
begin with. Of course, I am primarily working with web sites and
internal business apps. I understand that if you are doing high
performance graphics for games (Which is what Richard does IIRC)
optimizing is a bigger part of the job.

I have also done the code kata of test-driving bubble sort. In that
case I did test-drive a solution, and it ended up looking almost
nothing like the canonical implementation. But, that feels contrived
to me, because I know that if my tests are compelling me to sort
something the real answer is the standard library .sort(). In Java I
know that is a modified quicksort (or a modified mergesort, depending
on which library class we are talking about.) I know that it was done
pretty well by folks who know more about it than I do.

I like the way they put it here:
http://leepoint.net/notes-java/data/arrays/70sorting.html Writing your
own sort is good education but poor professional practice. I think
that is true most of the time for sort, and it is sometimes just as
true for other algorithms like searches, encryption, random numbers,
etc. The skill comes in knowing how to recognize the cases where it
isn't true.

On Wed, May 26, 2010 at 9:11 PM, George Dinwiddie
<[email protected]> wrote:
>
>
>
> Adam, et al,
>
> Adam Sroka wrote:
> > BTW, testing intermediate state in order to drive a particular
> > implementation is not TDD. TDD is concerned with the behavior of the
> > objects in your system. Could I write a test that says, "line 6 of the
> > program shall say ..."? Sure I could, and it would compel a particular
> > implementation, but it would not even resemble TDD.
>
> I find that test-driving a particular algorithm is sometimes useful.
> I'll agree that it doesn't feel the same as TDD, though. At the Floyd
> Code Retreat, Corey Haines called this a form of Test First Development,
> distinct from TDD. I think I like that distinction.
>
> - George
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
> 


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/