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.

> For one: the others don't have layers.

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.

py.test is using an iterator to launch tests immediatly while looking
for them, the script is very fast

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)

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.

This would make a unique testing tool, for the Zope community,
and with a lighter way to write new tests, and with the command-line interface
they are used to since years

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to