On Mon, 28 Feb 2000 11:23:02 +0100, Martijn Faassen <faassen@vet.uu.nl> wrote:
Hi there,
Recently I've been reading some books [1] which put emphasis on the idea of unit testing. At the Python conference Joel Shprentz held a short talk about doing unit tests in Python [2]
Here is the basis of the strategy my team has been using for the last few months... 1. Do as much 'hard work' as possible in python modules that are not zope specific. Test these independantly from zope. ZCatalog is a good example of how this approach looks. 2. If there is some 'hard work' that can not be made zope-independant, then expose elemental segments of work in their own methods, then exercise these methods using xmlrpclib, urllib, or httplib. I consider this 'all model, no view', but the authors of [3] might disagree. If you find this type of unit grows beyond 'small' then we have preferred to split it into two units, factoring out a zope-indepenent core. 3. Make sure you have a good separation of functionality from presentation. This is recycling old advice, but its worth stating how it applies to testing: Presentation should be testable by eyeballs alone. So far this item has been the hardest to follow.
Doing unit tests in Python isn't hard to do.
Python is the most unit-test-friendly language I know.
Regards,
Martijn
Thanks for starting an interesting thread.
[1] Martin Fowler, ed., Refactoring: Improving the Design of Existing Code, Addison Wesley Longman, 1999
Kent Beck, Extreme Programming Explained, Addison Wesley Longman, 1999
[2] http://www.python.org/workshops/2000-01/proceedings/posters/shprentz/shprent... http://c2.com/cgi/wiki?PythonUnit
[3] http://www.zope.org/Resources/Mozilla/ZWiki/ZopeMVC http://www.zope.org/Resources/Mozilla/ZWiki/ModelViewController
Toby Dickenson tdickenson@geminidataloggers.com