Re: [Zope-dev] New test summarizer format
Hello, On Thu, 24 Mar 2011 10:51:44 +0100 you wrote: Hello, * Adam GROSZERagros...@gmail.com [2011-03-23 08:45]: On Wed, 23 Mar 2011 07:43:26 +0100 you wrote: On a tangentially-related note, what happened to the proposed new summarizer formatting? Half a year ago (or whenever), I got the impression it was going to be ready in a few days, but it seems it never happened. What is needed to get this switched? You mind walking over to Theuni and asking him? ;-) Oh. Right. Sure. *walks over and back* So. Theuni says, the code[1] (based on the current aggregator script) is probably pretty much ready for deployment. This is a script to be run by cron that scrapes the HTML list archives of the zope-test list. I haven't looked at it yet, so I don't know how ready probably pretty much actually means. If I understood this correctly, the current aggregator runs courtesy of Stephan Holek. I guess it would be a good idea to get this somewhere closer to the Zope Foundation, so I'd rather we work something out with Jens Vagelpohl how/where to run this than throw it up on one of our boxes here at gocept. Adam, do you want to tackle this? Otherwise, I can do it, but I don't know when I get enough round toits to make it happen. Wolfgang [1] http://zope3.pov.lt/trac/browser/Sandbox/ctheune/testsummarizer I'm rather busy nowadays. But it seems like it's about bugging Stephan Holek to stop the current one and bugging Jens to start the new one, or? Unless the script is broken. Could you run that script -- worst case we'll have 2 mails for a day -- for testing? Seems like it has the settings for gocept and I don't really have an SMTP server here handy. -- Best regards, Adam GROSZER -- Quote of the day: Don't tell any big lies today. Small ones can be just as effective. ___ 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] Test fixture concepts
On Mon, Mar 28, 2011 at 5:27 PM, Martin Aspeli optilude+li...@gmail.com wrote: On 28 March 2011 15:45, Tres Seaver tsea...@palladion.com wrote: The vast majority of the doctest testcases in zope.* packages fall into this category: poor isolation, lots of edge cases which would obscure any real narrative docs, of which there are almost none. I believe the conflict is intrinsic, here, and not just an accident of careless / naive implementation: exercising all the preconditions of the contract of the function-under-test makes for really poor documentation, but is essential to good testing. Agree. Here's what I've found and learned the hard way: doctests are sometimes easier / more fun to write the *first* time I write tests. It's easy to just start writing, and the narrative helps me think about what I'm doing. Yup. Plus, it feels like I'm saving time on writing docs. And it doesn't because tests != docs. I've found that docs need to be written from an entirely different point of view. They are much worse all subsequent times. Maintenance becomes a soup. I've only found this to be the case if all tests are put in the same document. Keep in mind that unit tests can be a maintenance disaster too. I speak from experience. Some key factors in maintainability: - Is the intent clear. Unit tests don't do anything to make intent clear. Doctests don't force you to make intent clear. - Coupling between different tests. Arguably doctests encourage this by making it easy to glom many unrelated tests into the same document, but this can and does happen with unit tests as well, especially if a lot of setup is needed. Quick tests for edge cases feel like they obscure the narrative, Yup, they do! so I may forgo them. Which is a mistake. You should create separate tests. I typically put large tests, dealing with main use cases where there is a definite flow of activity in '.test' files. I do these in separate files because they're easier to write that way. I use a '.test' suffix to avoid the pretense that these are documentation. I put edge-case tests in small docstrings in testing modules. I'm not really religious about using doctests for this, but I find small edge-case doctests easier to read than traditional unit tests. It's possible that I'd like py.test tests as much. Refactoring is painful. It all depends on how well the tests are written and this applies equally no matter what format is used. Tool support is poorer, True ... And people find the docs underwhelming. tests != docs This was a lesson learned. If I'm doing it wrong, I'd like to see it done right. You might check out the bobo and zc.ngi docs and tests and let me know what you think. Manuel is kind of cool, but I'm not sure it really addresses the issue. It's a better doctest, not a better unittest. You may be missing the point. When writing docs, the primary goal is to guide the user to understanding as effectively as possible. The focus is on the user and their goals. A secondary, but important goal is making sure what you say in documentation is true. Manuel helps with the second goal without compromising the first goal. When writing tests, the focus is on the software and assuring that it is working correctly. Manuel can help here too by making some things easier to express and by being a better doctests, but the main goal of manuel is to enable writing good documentation that is still executable. One of the main objections to unittest(2) seems to be that it's Javaesque. Yes, JUnit was the first library to solidify many of the current, cross-language testing patterns. We shouldn't be so NIH-stricken that we can't see the benefit of being consistent with patterns used in most other languages and test frameworks these days. It's not about NIH, it's about ceremony. Java and it's culture are all about ceremony that just get in the way. py.test and (modern uses of) doctest are in many ways a reaction to that ceremony. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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 )
[Zope-dev] Zope Tests: 74 OK, 14 Failed
Summary of messages to the zope-tests list. Period Mon Mar 28 11:00:00 2011 UTC to Tue Mar 29 11:00:00 2011 UTC. There were 88 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 23 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 45 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:18:14 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036429.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:46:58 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036443.html Subject: FAILED : Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:47:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036444.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 17:06:20 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036453.html Subject: FAILED : winbot / zc_buildout_dev py_254_win32 From: buildbot at winbot.zope.org Date: Mon Mar 28 17:28:13 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036466.html Subject: FAILED : winbot / zc_buildout_dev py_265_win32 From: buildbot at winbot.zope.org Date: Mon Mar 28 17:28:34 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036467.html Subject: FAILED : winbot / zc_buildout_dev py_265_win64 From: buildbot at winbot.zope.org Date: Mon Mar 28 17:28:45 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036468.html Subject: FAILED : winbot / zc_buildout_dev py_270_win32 From: buildbot at winbot.zope.org Date: Mon Mar 28 17:28:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036469.html Subject: FAILED : winbot / zc_buildout_dev py_270_win64 From: buildbot at winbot.zope.org Date: Mon Mar 28 17:29:06 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036470.html Subject: FAILED : Zope 3.4 Known Good Set / py2.4-64bit-linux From: buildbot at pov.lt Date: Mon Mar 28 21:01:33 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036485.html Subject: FAILED : Zope 3.4 Known Good Set / py2.4-32bit-linux From: buildbot at pov.lt Date: Mon Mar 28 21:27:31 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036487.html Subject: FAILED : Zope 3.4 Known Good Set / py2.5-32bit-linux From: buildbot at pov.lt Date: Mon Mar 28 22:29:25 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036493.html Subject: FAILED : winbot / z3c.rml_py_265_32 From: buildbot at winbot.zope.org Date: Mon Mar 28 22:34:09 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036494.html Subject: FAILED : winbot / z3c.coverage_py_265_32 From: buildbot at winbot.zope.org Date: Mon Mar 28 23:05:01 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036495.html Tests passed OK --- Subject: OK : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 14:47:56 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036418.html Subject: OK : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 14:50:28 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036419.html Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 14:59:29 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036420.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:00:53 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036421.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:02:16 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036422.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:03:44 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036423.html Subject: OK : Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:05:08 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036425.html Subject: OK : Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:05:11 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036424.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:10:52 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036426.html
Re: [Zope-dev] [buildout] private releases
Hello, On Fri, 25 Mar 2011 19:24:05 + you wrote: Hi Christian, On 25/03/2011 16:49, Christian Theune wrote: the German speaking Zope Users Group (DZUG e.V.) organizes a series of 4 sprints this year to support feature development within the proximity of the ZTK and solve problems encountered by Zope, Plone and Python developers. snip Topics == * Discussing how to deal with private releases FWIW, I've had no problems with this, here's a sample buildout.cfg: [buildout] extensions = lovely.buildouthttp find-links = https://example.com/password/protected/folder ...and just dump the .tgz sdists in that folder. Of course, if you don't need password protection such as when you have your egg server on a private network, you just need the find-links. I'm not really sure why people have written a complicated array of egg servers and the like when a simple http or file system served folder is just fine ;-) Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. -- Best regards, Adam GROSZER -- Quote of the day: To look up and not down, To look forward and not back, To look out and not in, and To lend a hand. - Edward Everett Hale ___ 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] Test fixture concepts
On Tuesday, March 29, 2011, Jim Fulton wrote: so I may forgo them. Which is a mistake. You should create separate tests. I typically put large tests, dealing with main use cases where there is a definite flow of activity in '.test' files. I do these in separate files because they're easier to write that way. I use a '.test' suffix to avoid the pretense that these are documentation. I put edge-case tests in small docstrings in testing modules. I'm not really religious about using doctests for this, but I find small edge-case doctests easier to read than traditional unit tests. It's possible that I'd like py.test tests as much. Yeah, Marius led me recently to that path too. Write a narrative in text files and use doc strings of functions to do edge cases (or when you don't have time for the narrative). I am getting used to it. I still much prefer the sort of output comparison that doctests/manuel gives me over the assertion language that unittest.TestCase requires. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] Test fixture concepts
On 3/29/11 14:40 , Stephan Richter wrote: On Tuesday, March 29, 2011, Jim Fulton wrote: so I may forgo them. Which is a mistake. You should create separate tests. I typically put large tests, dealing with main use cases where there is a definite flow of activity in '.test' files. I do these in separate files because they're easier to write that way. I use a '.test' suffix to avoid the pretense that these are documentation. I put edge-case tests in small docstrings in testing modules. I'm not really religious about using doctests for this, but I find small edge-case doctests easier to read than traditional unit tests. It's possible that I'd like py.test tests as much. Yeah, Marius led me recently to that path too. Write a narrative in text files and use doc strings of functions to do edge cases (or when you don't have time for the narrative). I am getting used to it. I still much prefer the sort of output comparison that doctests/manuel gives me over the assertion language that unittest.TestCase requires. FWIW unittest2 has much nicer output if you use the new assert methods. Wichert. ___ 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] Zope Tests: 74 OK, 14 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:18:14 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036429.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:46:58 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036443.html Subject: FAILED : Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:47:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036444.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 17:06:20 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036453.html These four are still dying in the bootstrap step, without any kind of useful output. I just tried to reproduce one without success:: - --- % -- $ cd /tmp $ svn co http://svn.zope.org/repos/main/zopetoolkit/branches/1.0 A1.0/LICENSE.txt A1.0/development.cfg A1.0/zopeapp-versions.cfg A1.0/bootstrap.py A1.0/buildout.cfg A1.0/COPYRIGHT.txt A1.0/ztk.cfg A1.0/README.txt A1.0/zopeapp.cfg A1.0/ztk-versions.cfg A1.0/index.rst U 1.0 Checked out revision 121155. $ cd 1.0/ $ /opt/Python-2.6.5/bin/python bootstrap.py Creating directory '/tmp/1.0/bin'. Creating directory '/tmp/1.0/parts'. Creating directory '/tmp/1.0/eggs'. Creating directory '/tmp/1.0/develop-eggs'. Generated script '/tmp/1.0/bin/buildout'. - --- % -- 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/ iEYEARECAAYFAk2R6zUACgkQ+gerLs4ltQ7w0QCfZ/jXytAG9yNbu8Zw23gyingt rYAAoM9jxNwqru2WK7cjYcEHw+oRKkwB =qWYz -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] Zope Tests: 74 OK, 14 Failed
On Tue, Mar 29, 2011 at 10:22:45AM -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Mon Mar 28 15:18:14 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036429.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:46:58 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036443.html Subject: FAILED : Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 16:47:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036444.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Mar 28 17:06:20 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036453.html These four are still dying in the bootstrap step, without any kind of useful output. I just tried to reproduce one without success:: - --- % -- $ cd /tmp $ svn co http://svn.zope.org/repos/main/zopetoolkit/branches/1.0 A1.0/LICENSE.txt A1.0/development.cfg A1.0/zopeapp-versions.cfg A1.0/bootstrap.py A1.0/buildout.cfg A1.0/COPYRIGHT.txt A1.0/ztk.cfg A1.0/README.txt A1.0/zopeapp.cfg A1.0/ztk-versions.cfg A1.0/index.rst U 1.0 Checked out revision 121155. $ cd 1.0/ $ /opt/Python-2.6.5/bin/python bootstrap.py Creating directory '/tmp/1.0/bin'. Creating directory '/tmp/1.0/parts'. Creating directory '/tmp/1.0/eggs'. Creating directory '/tmp/1.0/develop-eggs'. Generated script '/tmp/1.0/bin/buildout'. - --- % -- I also couldn't reproduce the failure. -- 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] [buildout] private releases
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote: Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). -- Martijn Pieters ___ 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] [buildout] private releases
* Martijn Pieters m...@zopatista.com [2011-03-29 20:59]: On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote: ...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). (Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated egg server business required. Wolfgang ___ 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 )
