Re: [Zope3-dev] Re: Windows eggs
On Saturday 14 July 2007 18:13, Marius Gedminas wrote: http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. Merged. Yipee! 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
On Saturday 14 July 2007 15:30, Benji York wrote: 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. Right, z3c.etestbrowser does this already. I wish they would have done this with a different object altogether, but they extended the TestBrowser class. But then I do not have enough objectstion to write a new package. 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
On Saturday 14 July 2007 04:24, Marius Gedminas wrote:
- 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.
I disagree. API reference should be automatically created. Text files are
there to explain the API to someone who wants to use it. I write text files
like I would write a lab report or a book on the subject.
- 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)
I have not done this, because most interesting functions/methods are not that
simple. Also, I really enjoy not having long documentation strings in the
code anymore. That's a huge win coming from interfaces, in my opinion.
- 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
I never do this anymore. If I have a collection of utility functions, I Still
put them in a text file, because text files allow me to concentrate on
documentation. In you example above, for example, I miss a lot of explanatory
text. When I have utility functions that I want to explain independently,
then I simply create one section/chapter per function.
- 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.
I agree. You should give z3c.etestbrowser a try. It is based on lxml and
supports XPath querying. I switched all my functional testing to etestbrowser
now.
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
[Zope3-dev] Re: problem with zope.testbrowser
Adam Groszer wrote: Did something at /repos/Zope3/branches/adamg-mechanize-update/, the biggest problems seems to be now, that ClientForm won't work in a subfolder. Any objections against putting it back to /src? It won't really matter much, I think, because the trunk of the Zope3 tree will unlikely see another release. You really want to branch the zope.testbrowser trunk and work there. Unfortunately, I've just seen that we don't pull in ClientForm and mechanize as eggs. They're actually included in the zope.testbrowser egg. That sucks. It'd be great if you could change that while you're at it. -- http://worldcookery.com -- Professional Zope documentation 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
Stephan Richter wrote: On Saturday 14 July 2007 15:30, Benji York wrote: 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. Right, z3c.etestbrowser does this already. I wish they would have done this with a different object altogether, but they extended the TestBrowser class. But then I do not have enough objectstion to write a new package. Perhaps someone can explain the utility of z3c.etestbrowser. As far as I can see, it just adds an etree attribute to browser instances. That doesn't seem to have much advantage over just calling etree on browser.contents. I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. The programmatic approach like above is one option. Another would be to use a special checker that took into account HTML/XML structure. For example, it could interpret ellipses differently such that foo ...Text here/foo would match foo a=bText here/foo but not foobar/Text here/foo -- 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 Sunday 15 July 2007 10:44, Benji York wrote:
Right, z3c.etestbrowser does this already. I wish they would have done
this with a different object altogether, but they extended the
TestBrowser class. But then I do not have enough objectstion to write a
new package.
Perhaps someone can explain the utility of z3c.etestbrowser. As far as
I can see, it just adds an etree attribute to browser instances. That
doesn't seem to have much advantage over just calling etree on
browser.contents.
Right, right now it does not do much more. But I do not have to think about it
and just use the attribute. I usually end up writing one more utility
function that does an XPath expression selects the first result (which I am
usually interested in) and prints that. I think this would make a great
method on etestbrowser.
I'm doing some work with doctest right now, and am considering how to
make assertions about HTML/XML better. The programmatic approach like
above is one option. Another would be to use a special checker that
took into account HTML/XML structure. For example, it could interpret
ellipses differently such that
foo ...Text here/foo
would match
foo a=bText here/foo
but not
foobar/Text here/foo
I would not like that. I really, really like to use XPath to select an element
in the HTML structure. The method above would still require me to write
print browser.contents
...
foo ...Text here/foo
...
So I really like this much better:
print browser.xpath1('//foo')
foo a=bText here/foo
Of course, I really would prefer this:
print Introspector(browser).xpath1('//foo')
foo a=bText here/foo
This is so that the browser features and content inspection are separated.
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
Stephan Richter wrote:
I would not like that. I really, really like to use XPath to select an element
in the HTML structure. The method above would still require me to write
I think I miscommunicated. Let me combine your example and mine to
demonstrate what I was talking about. Say you have an HTML document and
you want to make assertions about a portion of it. You could use XPath
to extract part of the document and then use the smart ellipses to make
assertions about it. Like so:
browser.open(...)
Introspector(browser.contents).xpath('//foo')
foo ...Text here/foo
In the above example, the tester wants to extract the foo element, and
assert that its contents are Text here and that there are no child
elements. They don't want to make any assertions about it's attributes
so they put the ellipses there. Is that example clearer?
Of course, I really would prefer this:
print Introspector(browser).xpath1('//foo')
foo a=bText here/foo
This is so that the browser features and content inspection are separated.
Yep, I much prefer having this functionality in a separate object as
well; it's not really testbrowser specific.
--
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 Sun, Jul 15, 2007 at 08:34:43AM -0400, Stephan Richter wrote:
On Saturday 14 July 2007 04:24, Marius Gedminas wrote:
- 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.
I disagree.
Perhaps not. ;)
API reference should be automatically created.
Yes, absolutely, with something like pydoc/epydoc/pydoctor.
I was talking about regular programmer-facing documentation and couldn't
find a good word for it (tutorial? programmer's guide). The thing you
read to learn about the package, not the thing you use to look up some
details of some function.
Text files are
there to explain the API to someone who wants to use it. I write text files
like I would write a lab report or a book on the subject.
- 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)
I have not done this, because most interesting functions/methods are not that
simple.
Yes, these are very rarely applicable in my experience. Low-level
universal utility functions, mainly, not application business logic.
Also, I really enjoy not having long documentation strings in the
code anymore.
That's great, I completely agree.
That's a huge win coming from interfaces, in my opinion.
I wish pydoc knew about zope interfaces...
- 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
I never do this anymore. If I have a collection of utility functions, I Still
put them in a text file, because text files allow me to concentrate on
documentation.
Perhaps I did not get my point clearly accross. Python modules with
doctests are useful for testing the various corner cases that you did
not test in the corresponding .txt file.
If you put the tests for all your corner cases into the documentation,
it quickly becomes unreadable.
In you example above, for example, I miss a lot of explanatory
text.
I was trying to keep the email short. I usually have a sentence
explaining each set short sequence of doctest assertions that do
something and then inspect the result.
When I have utility functions that I want to explain independently,
then I simply create one section/chapter per function.
Right, but test_foo.py is never about documentation, it's about isolated
unit tests.
Marius Gedminas
--
I noticed that Open Source proponents using MacOS X have developed highly tuned
excuses, similar to those that smokers have about why cigarettes are good for
you.
-- Miguel de Icaza,
http://primates.ximian.com/~miguel/archive/2004/Aug-03.html
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 Sun, Jul 15, 2007 at 10:44:35AM -0400, Benji York wrote: I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. Fixing https://bugs.launchpad.net/zope3/+bug/126169 would make my life easier. Marius Gedminas -- Microsoft -- because God hates us. 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
Marius Gedminas wrote: On Sun, Jul 15, 2007 at 10:44:35AM -0400, Benji York wrote: I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. Fixing https://bugs.launchpad.net/zope3/+bug/126169 would make my life easier. I wonder if that behavior is present in the mainline doctest (the one included in the Python standard library). If so, reporting the issue to the Python team would be appropriate. My desire is that zope.testing will stop including a forked doctest. -- 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
Marius Gedminas wrote: 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. Yay! I'm already using it. :) 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). The test runner could look at the top level stdout and pass the information to subprocesses. 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. It'd be nice to have a -C option that disables -c for when your test runner has -c included in the default options (as I intend to do with mine). -- 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
