Hi, On Thu, May 15, 2008 at 02:19:17PM +0200, Tarek Ziadé wrote: > On Thu, May 15, 2008 at 2:10 PM, Christian Theune <[EMAIL PROTECTED]> wrote: > > On Thu, May 15, 2008 at 01:43:05PM +0200, Wichert Akkerman wrote: > >> Previously Tarek Ziadé wrote: > >> > I am comparing nose, py.test and zope.testing, and I realized > >> > zope.testing does not install a console script at > >> > Python level. > >> > > >> > it is not really a problem when working with a buildout-centric > >> > approach (thanks to zc.recipe.testrunner), > >> > but how can zope.testing be used with plain Python package ? > >> > > >> > Is there any installer available, that would allow running > >> > zope.testing from the shell ? > >> > > >> > To advocate zope.testing, I need to be able to demonstrate it can be > >> > used like the other tools available out there :D > >> > >> Is there a reason to advocate zope.testing over the others? Would it > >> perhaps make more sense to use one of the more widely used tools instead > >> of maintaing our own testing toolkit? > > Good question, > > I am not through in my comparison work, but the range of features are > quite interesting in zope.testing ihmo, compared to others, and the zope > community is used to it.
Make sure you look at the trunk as well. I did some major refactorings on the grok sprint. > Yes, and other provides test fixtures at method, class, module and > (nose) package level. > > Although, py.test and nose provide a lighter approach where there's no need > to use the unittest base classes, as the tools wraps on the fly any > function, class so there's no need for extra boiler-plate code. The refactoring would be able to do that with a plugin. > py.test is using an iterator to launch tests immediatly while looking > for them, the script is very fast Even when gathering thousands of tests, this usually takes less than 1% of the time that the tests actually take to run. So it's a nice point but not that important IMHO. > This work i am doing is for a book, but I can publish the conclusion here if > it can help making a decision on this. > > At this point I think that the work being done by Collin Winter in Python 3K > will lead to a new testing framework in Python/unitest that will be > less Java-oriented > and lighter for test writer. > > From there, the third party libraries will probably be reduced to the > test discovery > part. (I don't think this will be integrated in python but I might be wrong) And reporting and integrating debugging tools and ... I guess. > My point of view is that zope.testing should evolve a little bit to be usable > naturally from the command line like others, and maybe be more flexible in the > discovering part, by wrapping tests that are not based on TestCase. The refactoring should allow this more easily. Christian -- Christian Theune · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )