Re: Merge proposal: tseaver-better_unittests branch of zope.interface
Tres Seaver <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote: > * Tres Seaver <[email protected]> [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! Thank you! >> 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.) Great, thanks! >> 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? The 'docs' and 'dev' aliases are defined in setup.cfg:: $ tail -n -3 setup.cfg [aliases] dev = develop easy_install zope.interface[testing] docs = easy_install zope.interface[docs] and their extras_require in setup.py:: $ egrep -B 2 "(testing_extras|'docs')" setup.py features = {'codeoptimization': codeoptimization} tests_require = ['zope.event'] testing_extras = tests_require + ['nose', 'coverage'] -- tests_require = tests_require, install_requires = ['setuptools'], extras_require={'docs': ['Sphinx'], 'test': tests_require, 'testing': testing_extras, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [email protected] 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/ iEYEARECAAYFAk9xr0wACgkQ+gerLs4ltQ4ihACg22pNtSDSrBpJ6jHEijmqJKc5 ihcAnAyjrukF6ukG8XVuyZREup89q1nr =v9nN -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - [email protected] 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 )