On 10/24/07, Robert Dober <robert.dober / gmail.com> wrote:
> On 10/24/07, Rick DeNatale <rick.denatale / gmail.com> wrote:
  Paraphrasing, you should test before you optimize, and use tdd/bdd.

> > I usually find that it really doesn't matter how fast things run if
> > they produce the wrong results.
> >
> Funny you say that Rick, because I was thinking about the role testing
> should have in this.
> I kind of ponder of writing two test suits for my projects, one which
> clearly is BDD (shall be) and one that kind of replaces very defensive
> programming style full of assertions.
> Now this is indeed a dangerous road because one might fall
> into the trap of implementing a straight jacket, killing the duck ;) etc.
>
> I still believe however that such "microtests" can be a valuable tool
> and might be
> more useful to find some errors than debuggers, depending on the type
> of error of course.
> Any thoughts, experiences about/with that approach?

I should, and probably will eventually, answer this more fully on my
blog, but off the top of my head

1) I'm not sure what you mean by the second type of test suite.  I
don't think you're talking about putting test assertions into the
code.  If you're not I'm not sure I see the real distinction

2) That said, I firmly believe that tests belong outside of the code
under test.  We talked about this some time ago when Trans asked for
opinions of the inplace tests in facets.  I distinguish between
instrumentation and test equipment.  Instrumentation is writing code
to be testable, but the 'bulky' test equipment doesn't weigh down the
F1 car being tested.

3) The chicken typing, I recently wrote about (and I like the term the
more I use it) is just that, weighing down the car unnecessarily.  If
the code will fail it's going to fail with or without the chicken
tests, and usually in a way that the chicken tests fail to anticipate.
Furthermore, introducing the chicken tests introduce additional ways
for the code to fail unnecessarily when the chicken tests report false
positives.

4) Getting back to the distinction between two types of test suite.
Personally, the attitude and approach to testing is much more
important than Sapir-Worff considerations, syntax, and whether you
call it TDD or BDD or call them tests or specs.  IMHO BDD is a sect of
the main test-first religion, and things like RSpec are kind of like
fancy exercise equipment.  If it helps you acquire the proper attitude
towards test first design that's great.  To my mind, when I've looked
at the bdd tools, although the have some nice ancillary features, I've
sensed that they are a little too intrusive on the code under test for
my taste, so I'd rather just use 'free weights' such as Test::Unit and
discipline.

Just like exercise equipment, neither does much good if you just use
it for a clothes rack! <G>

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/