Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Jim Washington [EMAIL PROTECTED] wrote: Doesn't the published object, being a view class, have context and request as instance variables? Well, yes. But these are also available directly in the Publication.callObect() method, and neither of them are available in the IResult, typically. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Fri, Jul 13, 2007 at 02:03:04PM -0400, Jim Fulton wrote: Of course, I'm a big fan of doctest. Not all tests are documentation though, even if they are written as doctest. I'm happy with what we've done. We're making good incremental progress. I think though that many of our doctests that aspire to be documentation are actually not good documentation. IMO, we need to separate tests into 2 classes: executable documentation and tests. +infinity Absolutely! Trying to reach two unrelated goals (comprehensive tests + human-friendly documentation) with one file is just too hard, if not impossible. The executable documentation needs to be **much more readable than it is now**. FWIW, here's a very good example of executable documentation: https://storm.canonical.com/Tutorial Marius Gedminas -- We have enough youth, how about a fountain of SMART? signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Fri, Jul 13, 2007 at 11:09:30PM +0200, Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Stephan Richter wrote:
I think in the long term it will be most beneficial, if we convert all
tests
to doctests; then a reasonable on-line documentation is not that hard to
provide.
- -1. Good tests don't always make good documentation; I prefer the
isolation of traditional unittests for anything other than main line
use cases, for which doctests are best suited.
Amen. I find failing doctests to be much harder to debug as well. I use
doctests as a method to make sure examples in my documentation are
correct, which is very useful.
Doctests are hard to get right. I've finally settled on classifying my
tests into four categories and using different styles for them:
- API documentation: human readability is the primary concern, doctests
are in there just to make sure the documentation stays up to date.
These are .txt files.
- Short usage examples: sometimes it's simpler to show an example than
to describe the function in words:
def parse_date(date_string):
Parses an ISO-8601 date.
parse_date('2007-07-14')
datetime.date(2007, 7, 14)
This is the only case when I allow doctests in code modules.
Putting long test suites in class/function docstrings clutters the
code and makes it harder to read.
- Unit tests: there are many of those, they're independent (thus a
single .txt for a collection of tests is a Bad Idea), they're short
(so understanding and debugging is easy) and expressive. I put
those into .py files full with functions that look like
def doctest_FooClass_does_this():
Test that FooClass is able to ...
foo = FooClass()
results = foo.do_this()
for fruit, score, comments in results:
... print fruit.ljust(10), '|', score.ljust(5), '|',
comments
Orange | 9 | Tastes good, a bit sour
Apple | 8 | Varies
and have a traditional test_suite() function at the end that returns
a DocTestSuite with the appropriate setUp/tearDown/optionflags.
In effect this is a more or less direct translation of the
traditional unittest tests. I find that rewriting the assertions
into doctest format helps me make the tests more readable. Compare
the above with
class TestFooClass(unittest.TestCase):
def test_does_this(self):
foo = FooClass()
results = foo.do_this()
self.assertEquals(results,
[('Orange', 9, 'Tastes good, a bit sour'),
('Apple', 8, 'Varies')])
and especially compare the output you get when the test fails.
- Functional tests: these are .txt files that use zope.testbrowser and
are the hardest to debug. There ought to be a better way to make
assertions about HTML output than using ELLIPSIS and then pulling
your hair out looking at huge and incomprehensible diffs.
Digression: syntax highlighting the diffs helps immensely.
Check out http://svn.zope.org/zope.testing/branches/colorized-output/
Another digression: this is why I want Zope 3 to run on Python 2.5.
I want to make XPath queries on the HTML, and I hope I'll be
able to do that with cElementTree.
Marius Gedminas
--
Added mysterious, undocumented --scanflags and --fuzzy options.
-- nmap 3.0 announcement
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sat, Jul 14, 2007 at 11:24:36AM +0300, Marius Gedminas wrote: Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ A picture is better than five hundred lines of code: http://mg.pov.lt/blog/europython-2007-sprints-2.html Marius Gedminas -- An algorithm must be seen to be believed. -- D.E. Knuth signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Saturday 14 July 2007 04:05, Marius Gedminas wrote: Absolutely! Â Trying to reach two unrelated goals (comprehensive tests + human-friendly documentation) with one file is just too hard, if not impossible. While it cannot be done in one file, I think it can be done in one style of writing. I have found that modules do not just split up in logical units, but also in usage. I tend to write one text file per module. Thus, naturally, some will read more like usage instructions and others like API documentation. Another good method is to write a simple example first explaining the most common usage and dive into the special cases later on. Of course, this style of writing is common in introductory science/engineering books and is nothing new. For functional tests I use a somewhat different approach, writing one text file per user and task, and name it something like admin-createsite.txt. BTW, I think the Storm tutorial is okay, but not exceptionally good. At the beginning it lacks introduction of what storm is and what its goals are. While a specific example is used in the tutorial all the writing is done generically talking about programming concepts. This is like talking about the gravitational force in physics and use a flying canon ball as an example. Something that attracts me is the choice of small sections/chapters. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Previously Marius Gedminas wrote: - Unit tests: there are many of those, they're independent (thus a single .txt for a collection of tests is a Bad Idea), they're short (so understanding and debugging is easy) and expressive. I put those into .py files full with functions that look like def doctest_FooClass_does_this(): Test that FooClass is able to ... foo = FooClass() results = foo.do_this() for fruit, score, comments in results: ... print fruit.ljust(10), '|', score.ljust(5), '|', comments Orange | 9 | Tastes good, a bit sour Apple | 8 | Varies and have a traditional test_suite() function at the end that returns a DocTestSuite with the appropriate setUp/tearDown/optionflags. Until you have to step through the test with pdb, at which point it becomes very painful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Marius Gedminas wrote: - Functional tests: these are .txt files that use zope.testbrowser and are the hardest to debug. There ought to be a better way to make assertions about HTML output than using ELLIPSIS and then pulling your hair out looking at huge and incomprehensible diffs. Yep, assertions about HTML (or XML) are difficult to do with plain text. One option is to feed browser.contents to your favorite HTML (XML) parser. Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. I have a feature suggestion: it would be nice to have a switch to say colorize output, unless stdout isn't a terminal, so piping the output to a pager (or file) doesn't result in polluted output. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sat, Jul 14, 2007 at 03:30:22PM -0400, Benji York wrote: Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. Merged. I have a feature suggestion: it would be nice to have a switch to say colorize output, unless stdout isn't a terminal, so piping the output to a pager (or file) doesn't result in polluted output. There's a little complication: when you have test layers that don't support tearDown, some of the tests are run in a subprocess, where stdout isn't a terminal (it's a pipe), but all the output will be copied verbatim to the stdout of the parent process (which may or may not be a terminal). It's not that hard to remove the -c flag when you're adding |less to the command line. Or you could use |less -R and have colourful and scrollable output. Marius Gedminas -- Nothing ever goes missing that they don't look at me, ever since that time I lost my horse. As if that could be helped. He was white and it was snowing, what did they expect? -- Dolorous Edd in A Storm of Swords by George R. R. Martin signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
