[Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

Tue Mar 27 22:21:26 UTC 2012

On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
> 
>   http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/

Yay!

> The work is outlined in this document on the branch:
> 
> http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/README-better_unittest.txt?rev=124744&view=auto
> 
> For those who are into sausage factories, the bulk of the work is
> available on Launchpad:
> 
>   https://code.launchpad.net/~tseaver/zope.interface/better_unittests
> 
> The branch makes many fewer "Zope-y" assumptions about how it is
> developed.  In particular, in a fresh checkout, you can run the tests
> and build the docs with widely-used 3rd-party tools, without needing
> to set up a buildout::
> 
> ------------------------------ %< ---------------------------------------
>  $ svn co $ZSVN/zope.interface/branches/tseaver-better_unittests
>  ...
>   U   tseaver-better_unittests
>  Checked out revision 124746.
>  $ /opt/Python-2.7.2/bin/virtualenv .
>  New python executable in ./bin/python
>  Installing setuptools............done.
>  Installing pip...............done.
>  $ bin/python setup.py dev

Is that different from 'python setup.py develop'?  I've never seen 'dev'
before.

>  running develop
>  ...
>  Finished processing dependencies for zope.interface[testing]
>  $ bin/nosetests --with-coverage
>  ...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>  Name                               Stmts   Miss  Cover   Missing
>  ----------------------------------------------------------------
>  zope.interface                        30      0   100%
>  zope.interface.adapter               440      0   100%
>  zope.interface.advice                 69      0   100%
>  zope.interface.common                  0      0   100%
>  zope.interface.common.idatetime       98      0   100%
>  zope.interface.common.interfaces      81      0   100%
>  zope.interface.common.mapping         32      0   100%
>  zope.interface.common.sequence        38      0   100%
>  zope.interface.declarations          312      0   100%
>  zope.interface.document               54      0   100%
>  zope.interface.exceptions             21      0   100%
>  zope.interface.interface             378      0   100%
>  zope.interface.interfaces            137      0   100%
>  zope.interface.registry              300      0   100%
>  zope.interface.ro                     25      0   100%
>  zope.interface.verify                 48      0   100%
>  ----------------------------------------------------------------
>  TOTAL                               2063      0   100%
>  ----------------------------------------------------------------------
>  Ran 707 tests in 2.880s

Ooh, and I also see a tox.ini on that branch!  That's extremely welcome!

(Lately when I had to make some changes to zope.* packages I've been
kind of annoyed about the non-straightforwardness of testing all
supported Python versions.  I briefly tried tox, but didn't want to
spend hours figuring out how to make it play nice with buildout.)

Question: does the 100% coverage number mean both C code *and* Python
fallbacks are tested now?

Question: does 'bin/python setup.py test' work?

It seems to be becoming a sort of a universal standard for "run all the
tests of this Python package please", and is usually not that difficult
to hook up.  (If not, I may volunteer to hook it up.)

Question: can we still use zope.testrunner?

I like some of zope.testrunner's features a lot (like colorization, test
filtering options explicitly by module and by test name).  (I may also
volunteer to hook this up, if it's not hooked up.)

> 
>  OK
>  $ bin/python setup.py docs
>  running easy_install
>  Searching for zope.interface[docs]
>  ...
>  Finished processing dependencies for zope.interface[docs]
>  $ cd docs
>  $ PATH=../bin:$PATH make html
>  ...
>  build succeeded.
> 
>  Build finished. The HTML pages are in _build/html.
> ------------------------------ %< ---------------------------------------

Ooh, are we going to see zope.interface docs on readthedocs.org?

> In addition to minimizing "Zope-iness", providing full coverage using
> small, descriptively-named unittests makes the code more maintainable.
> For instance, I expect to build on top of these improved tests as the basis
> for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from
> a single codebase, without needing a translator like lib2to3.

Ooh, nice!

> I think it will also be easier to improve the docs, now that they no
> longer bear the burden of supplying coverage / regression testing for
> the code.  We can remove a bunch of extremely-terse fragments, and have
> the examples which remain focus more on improving the reader's
> understanding than exercising some corner case.
> 
> Unless the consensus is against it, I plan to merge this branch to the
> trunk early next week.

I'm +1 for this.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3/BlueBream consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.zope.org/pipermail/zope-dev/attachments/20120328/29443c6e/attachment.sig>