Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: 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 ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote: * 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! 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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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 - Zope-Dev@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 )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
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=124744view=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 setuptoolsdone. 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.interface30 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.sequence38 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.interfaces137 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
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 05:08 AM, Brian Sutherland wrote: On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: 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! Thanks for the support! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yP+IACgkQ+gerLs4ltQ5aawCfY5GhVswjgbDYTuVeZc0NyukP wPoAoKMPxLs034DbJmMg6/mwRqxBlR98 =ZEWK -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
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/ 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=124744view=auto I've a comment about this change, which was part of that large merge from launchpad commit: --- zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c (revision 118418) +++ zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c (revision 124742) @@ -980,5 +980,11 @@ } else -Py_INCREF(result); +{ + if (result == Py_None default_ != NULL) +{ + result = default_; +} + Py_INCREF(result); +} return result; It seems to be a bugfix for http://pad.lv/910987 from [1] [1] http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182 I failed to find any mention of this CHANGES.txt on that branch. Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 05:08 AM, Brian Sutherland wrote: On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: 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! Thanks for the support! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yQA8ACgkQ+gerLs4ltQ40LwCggtNkxJxKGsazi76KBz3IMM9c eUQAnj5aM1M1gZnryHwpjKjSswn8tzX2 =Rkao -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 06:21 PM, Marius Gedminas wrote: $ bin/python setup.py dev Is that different from 'python setup.py develop'? I've never seen 'dev' before. 'dev' is an alias (defined in 'setup.cfg' for the following:: setup.py develop easy_install zope.interface[testing] running develop ... Finished processing dependencies for zope.interface[testing] $ bin/nosetests --with-coverage ... Name Stmts Miss Cover Missing zope.interface30 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.sequence38 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.interfaces137 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.) I still use buildout for complicated application installs, but have grown to dislike it for testing library code. Question: does the 100% coverage number mean both C code *and* Python fallbacks are tested now? They both pass the same suite of tests. I can't guarantee 100% covereage of the C code, but given that it passes the same tests, I'm satisfied. Question: does 'bin/python setup.py test' work? Yes. I consider that a necessary-but-not-sufficient minium for any library. 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? You can bootstrap and run the buildout and then run 'bin/test'. 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? I'm not opposed in principle. :) 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
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 06:32 PM, Marius Gedminas wrote: I've a comment about this change, which was part of that large merge from launchpad commit: --- zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c (revision 118418) +++ zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c (revision 124742) @@ -980,5 +980,11 @@ } else -Py_INCREF(result); +{ + if (result == Py_None default_ != NULL) +{ + result = default_; +} + Py_INCREF(result); +} return result; It seems to be a bugfix for http://pad.lv/910987 from [1] [1] http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182 I failed to find any mention of this CHANGES.txt on that branch. Thanks for the catch. This was indeed a fix for a problem I uncovered while ensuring that the Python and C implementations passed the same test suite. I have update the 'CHANGES.txt` file on the branch to indicate the fix. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yeBcACgkQ+gerLs4ltQ6cRQCeI9K1J040qOWRI3OnB6Vu4t3M DgEAoLSnM4RBc3tcRivZFyWbbVARUpKg =9SeP -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@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 )