[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