Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Merge proposal: tseaver-better_unittests branch of zope.interface

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


tseaver at palladion

Mar 26, 2012, 2:38 PM

Post #1 of 11 (433 views)
Permalink
Merge proposal: tseaver-better_unittests branch of zope.interface

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

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=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
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

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.
- ------------------------------ %< ---------------------------------------

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.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
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/

iEYEARECAAYFAk9w4b8ACgkQ+gerLs4ltQ5rBQCgtZ1P96SowAzlKvZGVnWu/YM5
bD8AoIJZcL6uEotJMkVxFkLZqeMZCq9R
=uvZm
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


ws at gocept

Mar 26, 2012, 11:25 PM

Post #2 of 11 (426 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

* Tres Seaver <tseaver [at] palladion> [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!

> 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.)

> 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?

Wolfgang

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


brian at vanguardistas

Mar 27, 2012, 2:08 AM

Post #3 of 11 (425 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

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 [at] zope
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 )


tseaver at palladion

Mar 27, 2012, 5:15 AM

Post #4 of 11 (430 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

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

On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote:
> * Tres Seaver <tseaver [at] palladion> [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
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 - Zope-Dev [at] zope
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 )


marius at gedmin

Mar 27, 2012, 3:21 PM

Post #5 of 11 (425 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

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
Attachments: signature.asc (0.19 KB)


tseaver at palladion

Mar 27, 2012, 3:32 PM

Post #6 of 11 (422 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

-----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 tseaver [at] palladion
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/

iEYEARECAAYFAk9yP+IACgkQ+gerLs4ltQ5aawCfY5GhVswjgbDYTuVeZc0NyukP
wPoAoKMPxLs034DbJmMg6/mwRqxBlR98
=ZEWK
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


tseaver at palladion

Mar 27, 2012, 3:32 PM

Post #7 of 11 (423 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

-----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 tseaver [at] palladion
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/

iEYEARECAAYFAk9yQA8ACgkQ+gerLs4ltQ40LwCggtNkxJxKGsazi76KBz3IMM9c
eUQAnj5aM1M1gZnryHwpjKjSswn8tzX2
=Rkao
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


tseaver at palladion

Mar 27, 2012, 3:32 PM

Post #8 of 11 (422 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

-----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 tseaver [at] palladion
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/

iEYEARECAAYFAk9yQA8ACgkQ+gerLs4ltQ40LwCggtNkxJxKGsazi76KBz3IMM9c
eUQAnj5aM1M1gZnryHwpjKjSswn8tzX2
=Rkao
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


marius at gedmin

Mar 27, 2012, 3:32 PM

Post #9 of 11 (420 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

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=124744&view=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
Attachments: signature.asc (0.19 KB)


tseaver at palladion

Mar 27, 2012, 3:33 PM

Post #10 of 11 (420 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

-----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.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.)


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 this branch to the
>> trunk early next week.
>
> I'm +1 for this.

Thanks for the support!


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
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/

iEYEARECAAYFAk9yQEIACgkQ+gerLs4ltQ7bzQCgne6Zv0hJHwjA7HyeKum1ZysY
zcQAn31knVQ19/va/mjXl97oSWj9ELRN
=J/dt
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


tseaver at palladion

Mar 27, 2012, 7:31 PM

Post #11 of 11 (422 views)
Permalink
Re: Merge proposal: tseaver-better_unittests branch of zope.interface [In reply to]

-----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 tseaver [at] palladion
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/

iEYEARECAAYFAk9yeBcACgkQ+gerLs4ltQ6cRQCeI9K1J040qOWRI3OnB6Vu4t3M
DgEAoLSnM4RBc3tcRivZFyWbbVARUpKg
=9SeP
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.