[TIP] Interface vs Implementation Testing
holger at merlinux.de
Wed Apr 25 02:05:02 PDT 2007
Hi Essien, Max, hi all,
On Tue, Apr 24, 2007 at 17:02 +0100, Essien Ita Essien wrote:
> 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 :)
nicely put. In fact, I guess for complex programs involving many possible
combinations of user input and involved code/component interactions
unit tests are kind of neccessary to get to a maintainable and consistent
code base. For PyPy (being a full Python Interpreter and a Translation framework
to various backends) there would have been no way to make progress without unit-testing.
However, we used large functional tests (such as translating the whole Python
Interpreter to C) to try to identify some problems for which we then added unit-tests
to prove our theory about the problem. Then we fixed it.
Then again, the lines blurry - our unit-tests are often not strict unit-tests
but rather small functional tests. To me, there is a grey area and actually
i don't care too much. What matters to me regarding a test is:
will a failure and the related information/debugging facility
allow me to identify the underlying problem quickly?
are the tests fine-grained enough that i get one failure per problem
or do i rather get one failure, but 3 independent problems are underlying it?
can i run a significant fraction of tests speedily from my development machine?
i guess that strict unit-tests usually score quite well on these
criteria, but some functional tests can qualify as well IMO.
More information about the testing-in-python