ct at gocept
May 15, 2008, 5:40 AM
Post #9 of 12
(464 views)
Permalink
|
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 <ct[at]gocept.com> 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 ˇ ct[at]gocept.com
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[at]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 )
|
