On 9/12/08, ara.t.howard <ara.t.howard / gmail.com> wrote:
> it may sound heresy to some people on this list, and elsewhere, but i
> think dynamic languages like ruby require a, possibly additional (on
> top of tdd, bdd, whatever), rigorous process of *thought* and
> *discussion* to really build good code.  mechanical analysis is simply
> one way to approach coverage.
>
> a nice article summarizing what i'm saying
>
> http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html

Our philosophies are more aligned than you seem to think. Interesting
link. IMHO, testing is just one of the tools that should be used to
assess quality. I've long been a fan of code reviews, since long
before I'd ever heard of unit tests, dynamic languages, or any of
that.

I don't want to come across as your usual unit testing bigot, but it
certainly does have its place, which as I see it, is more than just
forcing you to think about what you're doing. But then, I don't
practice TDD or unit testing for that matter in the way its usually
done. Which is how I ended up on this thread in the first place.

> it's simply worth considering that 3 people in a room *now* maybe
> quite easily be able to achieve what current tools cannot, and may
> never be able to.

But consider that tools may achieve things that people can't, either.

> i think our minds are quite good at this - we have to select the data,
> write the coverage tools, the testing tools, the ci tools, and the
> code itself after all.  clearly software we write cannot be more
> effective that the people writing it.

I for one am not so confident about my ability to get all the edges on
my own. Tools are nice for things like exhaustive coverage of piddly
little details. I'm not so sure exactly what you're trying to get at
in the paragraph above, but it's always seemed the most pragmatic to
me to employ a combination of things. No tool will understand your
code for you, but the right tool can significantly enhance your
understanding of your code.