[TIP] Testing in General

[Ryan Freckleton]

On Tue, Mar 31, 2009 at 6:21 PM, Ben Finney
<ben+python at benfinney.id.au<ben%2Bpython at benfinney.id.au>
> wrote:

> Michael Gratton <michael at quuxo.com> writes:
>
> > Hi David,
> >
> > On Tue, 2009-03-31 at 18:20 -0400, David Blewett wrote:
> > > I was going to start by putting in coverage testing, so that I can
> > > start adding tests to the most active sections of my codebase. Any
> > > advice is appreciated.
> >
> > Just get some initial tests running, just a couple. This is
> > generally the biggest hurdle since it takes time away from doing
> > what you really want to do — hacking on your app. These initial
> > tests also serve as templates for adding more, making it easier to
> > do so.
>
> Also important is to realise that a code base which has evolved in the
> absence of unit tests will very likely be difficult to test.
>
> By which I mean, it will likely be architected in such a way that its
> internal interfaces are not loosely coupled, are too wide, do too much
> per unit, et cetera. One of the big advantages of focusing on
> testability of the code will be uncovering issues like this that have
> lain dormant in the code.
>
> For this reason I heartily agree with the advice to start by just
> adding one or two tests — but be scrupulous in ensuring the tests
> assert a *single* true or false statement about the code's behaviour.
> This may be shockingly difficult if the code is currently not designed
> well for this kind of inspection, but it is essential if your tests
> are to be useful in future debugging.
>
> You will learn a lot about your code from a different perspective,
> i.e. that of using your code's interfaces. You will likely need to
> re-factor large swathes of the code in order to get easily-tested
> interfaces; this is time well spent.
>
> Actually *writing* the tests will, I predict, be a miniscule portion
> of this initial time.
>
> --
>  \      “Some forms of reality are so horrible we refuse to face them, |
>  `\     unless we are trapped into it by comedy. To label any subject |
> _o__)        unsuitable for comedy is to admit defeat.” —Peter Sellers |
> Ben Finney
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
>
If you're feeling adventurous, you may want to try out pythoscope [
http://pythoscope.org/] to auto generate some tests for your existing code
base, it will give you at least a template from to test your existing code.

One of the best overviews of different automated testing I've found is xUnit
Test Patterns [http://xunitpatterns.com/]. Besides that, I'd recommend the
c2 wiki, although they have a definite bias towards XP and test driven
development [http://c2.com/cgi/wiki].

One generally useful strategy I've found for adding tests to pre-existing
code is to start with acceptance tests, that is, tests that target the
entire functionality of the system (e.g. an applications "main" function).
You may want to give that a shot, as well.

=====
--Ryan E. Freckleton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/testing-in-python/attachments/20090331/c2b44abc/attachment.htm