[TIP] Interface vs Implementation Testing

[Kumar McMillan]

On 4/21/07, Titus Brown <titus at caltech.edu> wrote:
> -> kinda know things still work.  You see where I'm going with that.  I
> -> tell developers on my team to **only** test interfaces and **never**
> -> test implementation and will slap wrists if I have to :)
>
> *boggle*
>
> Why not delete failing tests when the code they're testing no longer
> exists, and replace them with the tests that you wrote for the new code?

I coded a huge test suite once that primarily unit tested
implementation.  Since there were many tests, any time I wanted to
change the way the app was implemented (faster algorithm here, don't
need this class anymore, more methods now because of feature X) I
usually ended up spending a good deal of time updating and deleting
tests.  This just seemed unecessary to me and deterred me from relying
on the test suite as an indication of successful functionality.

Yes, the tests were written poorly and I've grown as a programmer
since then but I think the main reason they were bad was because they
tested implementation of units and not the interface that the units
were designed to be used with.

The grain of salt that I mentioned in the first post is that you will
always end up testing *some* implementation unless you only write
functional tests (not a good idea).  You'll always have to update some
and delete failing tests here and there, it's a given.  But I believe
in accumulating regression tests as much as possible and if
functionality doesn't change (which it usually doesn't, it is only
added to) then why have all this overhead in updating/deleting tests
all the time?

-Kumar