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] Basically a unit tests are some simple test functions that are associated with a unit of code (a python module). The tests exercise the code in the module, and either succeed or fail (there may also be an error due to an uncaught exception). Each time you change something in the module you run the associated tests. The idea is that this makes debugging easier, catching bugs more quickly and giving better diagnostics. Doing unit tests in Python isn't hard to do. I'm having more trouble thinking of a good way to do unit tests in Zope, though. Partially this is because Zope has various parts (the management interface for folders, ZClasses, product development), which each may need a different testing strategy. Partially this is because Zope currently mixes model and view together (though there are thoughts to do something about this [3]) -- unit tests are about testing code (methods and such), not user interfaces. Another problem is that much Zope code is not easy to test in isolation from Zope. Too much of the code depends on various Zope facilities (base classes, object database integration). Has anybody any ideas on how to do unit testing within the Zope framework? I'd like to try adopting somekind of unit test strategy for my Zope development. Regards, Martijn [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
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
participants (2)
-
Martijn Faassen -
Toby Dickenson