Eric Mahurin <eric.mahurin / gmail.com> writes:

> On 11/3/05, Christian Neukirchen <chneukirchen / gmail.com> wrote:
>
>> I'm still not sure whether instance_eval'ing tests is a good idea.
>
> That's my concern too. I'm not sure I trust the validity of of the tests
> since they are applied in a way that they are not used. This type of testing
> also ties the tests to a particular implementation. If you change the
> implementation (not the functionality), you'll likely have to change the
> testing since you are directly setting and accessing instance variables.

Also, how do you develop test-first with non-existing instance variables?

At least, one should make two groups of test, one that test
"blackbox", and one that test the actual implementation.  I'd write
the blackbox test first, and the whitebox tests in parallel to the
implementation.  That way, you can oversee the programming and still
test for implementation details.  The latter tests will need to be
thrown away on a reimplementation, of course.

> On the other hand, with some types of objects, you may not want to expose
> very much internal state at the API and this type of testing may make it
> much easier. I can draw an analogy from this to the hardware world - DFT
> (design for test) and ATPG (automatic test pattern generation) - where it is
> common practice to add control and observe points for testing (most state
> points at least). That is testing for defects, but even for functional tests
> it is common to at least have observability at some internal points in a
> chip. BTW, this is where I draw many of my software testing ideas from. I
> think the software world can learn some things from the hardware world in
> terms of testing.

I recently searched a bit about "behavior driven design" and found a
paper on "spec driven design"---which turned out to be about hardware.
-- 
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org