On Tue, Mar 31, 2009 at 6:21 PM, Ben Finney <span dir="ltr"><<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Michael Gratton <<a href="mailto:michael@quuxo.com">michael@quuxo.com</a>> writes:<br>
<br>
> Hi David,<br>
><br>
> On Tue, 2009-03-31 at 18:20 -0400, David Blewett wrote:<br>
> > I was going to start by putting in coverage testing, so that I can<br>
> > start adding tests to the most active sections of my codebase. Any<br>
> > advice is appreciated.<br>
><br>
> Just get some initial tests running, just a couple. This is<br>
> generally the biggest hurdle since it takes time away from doing<br>
> what you really want to do — hacking on your app. These initial<br>
> tests also serve as templates for adding more, making it easier to<br>
> do so.<br>
<br>
</div>Also important is to realise that a code base which has evolved in the<br>
absence of unit tests will very likely be difficult to test.<br>
<br>
By which I mean, it will likely be architected in such a way that its<br>
internal interfaces are not loosely coupled, are too wide, do too much<br>
per unit, et cetera. One of the big advantages of focusing on<br>
testability of the code will be uncovering issues like this that have<br>
lain dormant in the code.<br>
<br>
For this reason I heartily agree with the advice to start by just<br>
adding one or two tests — but be scrupulous in ensuring the tests<br>
assert a *single* true or false statement about the code's behaviour.<br>
This may be shockingly difficult if the code is currently not designed<br>
well for this kind of inspection, but it is essential if your tests<br>
are to be useful in future debugging.<br>
<br>
You will learn a lot about your code from a different perspective,<br>
i.e. that of using your code's interfaces. You will likely need to<br>
re-factor large swathes of the code in order to get easily-tested<br>
interfaces; this is time well spent.<br>
<br>
Actually *writing* the tests will, I predict, be a miniscule portion<br>
of this initial time.<br>
<br>
--<br>
\ “Some forms of reality are so horrible we refuse to face them, |<br>
`\ unless we are trapped into it by comedy. To label any subject |<br>
_o__) unsuitable for comedy is to admit defeat.” —Peter Sellers |<br>
<font color="#888888">Ben Finney<br>
</font><br>_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
<br></blockquote></div><br>If you're feeling adventurous, you may want to try out pythoscope [<a href="http://pythoscope.org/">http://pythoscope.org/</a>] to auto generate some tests for your existing code base, it will give you at least a template from to test your existing code.<br>
<br>One of the best overviews of different automated testing I've found is xUnit Test Patterns [<a href="http://xunitpatterns.com/">http://xunitpatterns.com/</a>]. Besides that, I'd recommend the c2 wiki, although they have a definite bias towards XP and test driven development [<a href="http://c2.com/cgi/wiki">http://c2.com/cgi/wiki</a>].<br>
<br>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.<br>
<br clear="all">=====<br>--Ryan E. Freckleton