* Tres Seaver <tseaver@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, especially - Where does bin/nosetests come from? - Where does "setup.py docs" come from? Wolfgang