Re: Struct is slow

On 10/24/07, Rick DeNatale <rick.denatale@xxxxxxxxx> wrote:
On 10/24/07, Robert Dober <robert.dober@xxxxxxxxx> wrote:
On 10/24/07, Rick DeNatale <rick.denatale@xxxxxxxxx> 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,
looking forward to it
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
Well better give an example, let us assume I want to write a package
that does err, what, no idea, just translation, than I would do
TDD/BDD somehow like follows, sorry I am not fluent in rspec but I
will just use something similar.

"Vive la France".shall.translate.to "Viva Italia"
"Je ne suis pas disponible".shall.translate.to "Gone fishing"

Now that is normally considered enough. But for my personal comfort
and anticipating problems and bugs inside my great plan of
implementation - experience speaking ;). I will add some tests very
closely related to the implementation. You see, something totally
opposed to the BDD thing.
E.g.

assert_kind_of? Enumeration, my_thingy.instance_variable_get("@words")
but better would be duck type tests
assert_respond_to? :each, my_thing.....
assert [:each, :map, :size] <= my_thingy.ivarget("@words").methods

The trick would be to identify some few strategic test points to get
alarmed about any
misconception or coding error.

2) That said, I firmly believe that tests belong outside of the code
under test.
I believe it too but less firmely.
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.
True but, I find Trans' tests rather instructive and he does not
really want a F1 car, but generally I agree with you. Libraries like
Factes and Labrador are somehow different because they are so
reflective and code pretty well describes what their code does.

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.
Here again I am with you, even instrumentation is a pain I guess and
that is why these microtests would be almost an exercise in
metaprogramming, I guess you would know some Smalltalk stories about
that.
The idea would be to identify stratigic points where being chicken
makes the duck more confident elswhere.
But not sure at all if that might work!
Furthermore, introducing the chicken tests introduce additional ways
for the code to fail unnecessarily when the chicken tests report false
positives.
Here I am losing you, should we not test because of the fear of 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.
I guess it does for me
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
that was true when I tested Rspec about 1.5 years ago, is it still?
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>
Err how did you know? ;)
R.
--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

.