Benji York wrote:
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).
I've added such an option. The -C switch makes sense, but I'm not
entirely happy with the --no-color version of the name, any
Benji York wrote:
Marius Gedminas wrote:
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
On Jul 13, 2007, at 5:09 PM, Wichert Akkerman wrote:
...
Amen. I find failing doctests to be much harder to debug as well.
Are you are of the post-mortem debugging features of the zope.testing
test runner? I find this helps a lot when debugging test failures.
On Jul 14, 2007, at 1:00
On Monday 16 July 2007 08:44, Jim Fulton wrote:
For me, post-mortem debugging or using set_trace is almost always
good enough. On those occasions where I really need to step through a
series of example, It's straightforward to convert them to a single
example.
Me too. Actually I only
On Sunday 15 July 2007 11:26, Benji York wrote:
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
On Sunday 15 July 2007 12:45, Marius Gedminas wrote:
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.
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
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
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
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
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
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
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.
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
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
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
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
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.
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:
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.
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
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
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.
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote:
* zope.interface
* zope.security
* zope.app.container
* zope.hookable
* zope.i18nmessageid
Could you or someone else make final source releases of these
first? I expect that some of these haven't changed since Zope 3.3.
We should not make
Jim Fulton wrote:
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote:
* zope.interface
* zope.security
* zope.app.container
* zope.hookable
* zope.i18nmessageid
Could you or someone else make final source releases of these first?
I expect that some of these haven't changed since Zope 3.3. We
Philipp von Weitershausen wrote:
P.S.: While looking around, I found that an ancient version of
zope.security actually exists as a Win32 egg on the CheeseShop:
http://cheeseshop.python.org/pypi/zope.security/3.4dev-r73262.
I wonder why my Windows buildout didn't find it. Perhaps the egg doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Jim Fulton wrote:
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote:
* zope.interface
* zope.security
* zope.app.container
* zope.hookable
* zope.i18nmessageid
Could you or someone else make final source releases
On Jul 13, 2007, at 7:04 AM, Jim Fulton wrote:
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote:
* zope.interface
* zope.security
* zope.app.container
* zope.hookable
* zope.i18nmessageid
Could you or someone else make final source releases of these
first? I expect that some of these
Tres Seaver wrote:
Point me at an existing source release, and I'll be happy to generate
corresponding windows eggs.
I made windows eggs for the latest version of zope.interface that's in
pypi.
Great. So we have zope.interface and zope.proxy and there'll be no need
for zope.thread. Which
On Jul 13, 2007, at 9:25 AM, Philipp von Weitershausen wrote:
Jim Fulton wrote:
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote:
* zope.interface
* zope.security
* zope.app.container
* zope.hookable
* zope.i18nmessageid
Could you or someone else make final source releases of these
first?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
Point me at an existing source release, and I'll be happy to generate
corresponding windows eggs.
I made windows eggs for the latest version of zope.interface that's in
pypi.
Great. So we
Tres Seaver wrote:
I realize that those aren't final releases, but they (most probably)
haven't changed significantly after these releases were made, which
would make it a waste of time if I had to tag and tarball them just for
the sake of a different version ID.
Doing proper release
On Friday 13 July 2007 11:23, Jim Fulton wrote:
Once we reach steady state, I'd like to see everything in the cheese
shop. Unfortunately, I hate crapping poorly packaged eggs there. :
( I'm not sure what to do about that given the time availability of
current volunteers.
It would be
On Jul 13, 2007, at 11:14 AM, Tres Seaver wrote:
...
I was trying to point out that doing only a partial
job (making binary installers for alphas) is likely to be troublesome.
Minor note:
For library-ish things, I've decided to *stop* making installers.
I'm only going to release binary
On Jul 13, 2007, at 11:31 AM, Stephan Richter wrote:
On Friday 13 July 2007 11:23, Jim Fulton wrote:
Once we reach steady state, I'd like to see everything in the cheese
shop. Unfortunately, I hate crapping poorly packaged eggs there. :
( I'm not sure what to do about that given the time
On Friday 13 July 2007 12:14, Jim Fulton wrote:
IMO, a could release should have:
- a good overview, and preferably
- on-line documentation
Right, I think this is well-served for packages that have doctests. I think
that your example of including the dotest files into the long description
On Jul 13, 2007, at 11:38 AM, Philipp von Weitershausen wrote:
I'm not sure what to do about that given the time availability of
current volunteers.
I would happily upload properly released stuff to the CheeseShop if
I had access.
Somebody thought I wanted to own pretty much everything
On Jul 13, 2007, at 1:14 PM, Stephan Richter wrote:
On Friday 13 July 2007 12:14, Jim Fulton wrote:
IMO, a could release should have:
- a good overview, and preferably
- on-line documentation
Right, I think this is well-served for packages that have doctests.
I think
that your example
Hi,
Philipp von Weitershausen wrote:
I tried to follow instructions from the web on how to get such a
toolchain running on my Windows machine (see post scriptum to my very
first email). It failed with an obscure error when compiling the
extension. So, it seems at the moment there's no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Friday 13 July 2007 12:14, Jim Fulton wrote:
IMO, a could release should have:
- a good overview, and preferably
- on-line documentation
Right, I think this is well-served for packages that have doctests. I think
Previously Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Friday 13 July 2007 12:14, Jim Fulton wrote:
IMO, a could release should have:
- a good overview, and preferably
- on-line documentation
Right, I think this is well-served
41 matches
Mail list logo
