[Zope-dev] zope.testing console script

[Christian Theune]

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