[Zope-dev] Circular dependency hell.

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Regebro wrote:
> On Fri, Apr 16, 2010 at 19:35, Tres Seaver <tseaver at palladion.com> wrote:
>>> == Suggestion 1 ==
>>>
>>> I think we should deprecate zope.testing. Completely. There has been
>>> some discussion about deprecating it for something else, but I think
>>> we should just deprecate it. Just say "Don't use zope.testing, it's
>>> pure evil". We can recommend another testrunner, and it seems nose is
>>> winning the wars in the Python world there, but I don't think we
>>> necessarily need to do that. Most testrunners will find the tests by
>>> themselves, and the tests should be runnable with any testrunner, so
>>> which one you use is a minor issue.
>> I'm +0 on this myself.  Certainly I don't think that we should have
>> packages hard-wire dependencies on zope.testing in order to run their
>> own tests.
>>
>>> Instead the big problem with getting rid of zope.testing is that many
>>> tests use other specific features like the doctest renormalizers etc.
>>> These could possibly be extracted into separate modules so you can use
>>> them with other testrunners.
>> Maybe instead we should strip zope.testing down so that it includes only
>> these bits (the ones that get imported by third-party test code), and
>> move the testrunner out to a separate package, e.g. 'zope.testrunner'.
>> I think Marius Gedminas already suggested such a thing:  we could update
>> zc.recipe.testrunner to use the new package, which would make existing
>> buildouts continue to wok.
> 
> That would be an improvement at least. Maybe we can determine what is
> actually in zope.testing and see what can be split out.
> 
> I know of three parts:
> 
> 1. The testrunner.

Right:  moving it out would clarify.

> 2. The special doctest

Already deprecated in favor of the stdlib module.

 and a module called doctestunit, of unclear use.

It is already deprecated, contains nothing but BBB imports and a funky
wrapper or ppprint.pprint (the way the wrapper is constructed is pretty
insane).  Unfortunately, it is widely used in ZTK tests, mostly in ways
which should be replace with the stdlib doctest module.  The ``pprint``
function could be moved into a new module, perhaps.

> 3. The doctest renormalizers.
> 4. Anything else?

:mod:`zope.testing.exceptions`
    used only by the custom doctest and the testrunner.  It could just
    move to the testrunner.

:mod:`zope.testing.formparser`
    Parses rendered HTML forms back to datastructures.  Maybe useful
    in tests which consume rendered output.

    No ZTK tests use this module.

:mod:`zope.testing.loggingsupport`
    Enable assertions about how code uses Python's logging module.

    No ZTK tests use this module.

    Tests in :mod:`zc.buildout`, :mod:`zope.app.appsetup`, :mod:`ZODB`,
    and :mod:`zc.lockfile` use this module.

:mod:`zope.testing.loghandler`
    *Another* module enabling assertions about how code uses Python's
    logging module.

    No ZTK tests use this module.

:mod:`zope.testing.module`
    Support for jamming a dummy module into sys.modules, and getting
    it out again in a testcase's tearDown..

    Tests in :mod:`zope.copy` and :mod:`zope.container` use this module.

    Tests in :mod:`ZODB` also use this module

:mod:`zope.testing.server`
    Runs an HTTP server (?!) in the middle of a functional test, and
    uses the stdlib 'webbrowser' module to make a request.

    No ZTK tests use this module.

:mod:`zope.testing.setupstack`
    Support for chaining together teardown functions in a stack

    No ZTK tests use this module.

    Tests in :mod:`ZODB` and :mod:`zc.lockfile` use this module.


> I think the doctest renormalizers can be used with standard doctest,
> so it might be feasible to extract those as well?

How about we move out the testrunner (including updating
zc.recipe.testrunner), clean out any remaining cruft, and release a new
major version containing only bits used in real-world tests?


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvIrw4ACgkQ+gerLs4ltQ4NCgCfaDGjIy3+dJs0EfkNEC47GdcI
ITIAoNmNVBE1GBF12nzi6JAKOpdxxE52
=ZlJ4
-----END PGP SIGNATURE-----