[Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

Tres Seaver tseaver at palladion.com
Tue Mar 27 12:15:08 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote:
> * Tres Seaver <tseaver at 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          tseaver at palladion.com
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-----



More information about the Zope-Dev mailing list