* Tres Seaver <tsea...@palladion.com> [2012-03-26 23:38]:
> 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,
- Where does bin/nosetests come from?
- Where does "setup.py docs" come from?


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

Reply via email to