[Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
Tres Seaver
Hash: SHA1
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/
The work is outlined in this document on the branch:
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
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
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.
- ------------------------------ %< ---------------------------------------
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.
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.
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9w4b8ACgkQ+gerLs4ltQ5rBQCgtZ1P96SowAzlKvZGVnWu/YM5
bD8AoIJZcL6uEotJMkVxFkLZqeMZCq9R
=uvZm
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope...@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Wolfgang Schnerring
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
That's an impressive feat, congratulations!
> 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.
>
> 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.
I haven't had time yet to review this in detail, but this is most
definitely the right direction: separate tests from documentation, make
the tests expressive and the documentation clear. Wonderful!
(I've I get some 'round toits, I'd much like to look through this; I'll
let you know if I find anything.)
> Unless the consensus is against it, I plan to merge this branch to the
> trunk early next week.
+1, please do.
> 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::
Since I've thinking along these lines recently ("why do I need buildout
if all I want is a testrunner?"), I'm curious as to how this works,
especially
- Where does bin/nosetests come from?
- Where does "setup.py docs" come from?
Wolfgang
Brian Sutherland
> 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.
>
> 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.
This sounds great, I think it's exactly the right way to go. It's just a
LOT of work, a BIG thanks for taking it on!
--
Brian Sutherland