[TIP] Interface vs Implementation Testing

[Essien Ita Essien]

Max Ischenko wrote:
> 
> 
> On 4/24/07, *Titus Brown* <titus at caltech.edu <mailto:titus at caltech.edu>> 
> wrote:
> 
>     -> 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.
> 
>     So, isn't this kind of an argument for functional and regression tests
>     only?
> 
>     (I'm honestly curious.  I haven't found much of a need for unit
>     tests in
>     my own code.)
I've been mostly silent and stealing ideas and lessons from others
so i guess i'd better contribute back a thought or two here ;-)

For me... I don't even do much of what you call functional testing, but 
what i find invaluable are those unit tests. How I normally develop is 
in quick spurts of small ideas that i'll eventually put together into a 
whole. for instance, I'm gonna need to read a files over the network, so 
i quickly code a function that does just that, i'm going to need to 
steganograph streaming data from various sources and stuff to files, so 
i quicly code functions needed to do just that.

The problem is that without the whole application, you really can't test 
these little bits and pieces. But with UNIT tests... the whole ball game 
changes. You are no more writing a bit application, but a small 
application that does just A for just B, and you can setup the small 
environment in your unittest, needed to get A or B to just work. Once 
its workign... you can safely plunk that functionality int a module
and be rest assured that when you actually call it in your big 
application... its gonna do just what you intended it to do.

When its time to do the putting together... if all your parts are 
working as expected in other small small applications (aka. Unit Tests).
You just go to sleep :)
> 
> 
> Functional tests work great when testing "base path" through the system. 
> But they don't work that great testing corner cases, unexpected 
> conditions and branch logic.
> 
> You can write unit tests which exercise a function/module with (all) 
> different code paths. The more high-level the test the less feasible it 
> becomes: number of permutations explodes and many code paths simply 
> aren't (easily) reachable from the top-level. That off-the-beaten-path 
> code still needs to be tested and there is no better tool for that than 
> unit tests.
> 
> YMMV, of course.
> 
> Max.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python