Re: Merge proposal: tseaver-better_unittests branch of zope.interface
Marius Gedminas <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <20120327222126.GB8834@platonas> |
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 _______________________________________________ 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 )
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9yPWYACgkQkVdEXeem148S3gCghlYfH73fs3um71QyzhsVZ59z NZ8An3EL6Mu9ObHY8TC7eMGOsCh/9hFX =AGFa -----END PGP SIGNATURE-----