[Python-Dev] Unittest/doctest formatting differences in 2.7a1? (original) (raw)

Olemis Lang olemis at gmail.com
Wed Dec 9 19:40:29 CET 2009

On Wed, Dec 9, 2009 at 12:45 PM, Ian Bicking <ianb at colorstudy.com> wrote:

On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro <lregebro at jarn.com> wrote:

> Evolving the tests to avoid depending on these sorts of implementation > details is reasonable, IMO, and cuold even be considered a bugfix by > the Zope community. Evolving doctest.py so it can handle this by itself would be considered a bugfix by me. :) It's about time doctest got another run of development anyway.

+1 ... that's why I implemented dutest BTW (I wanted more out of doctest ;o)

I can imagine a couple features that might help:

* Already in there, but sometimes hard to enable, is ellipsis.  Can you already do this?  >>> throwanexception()  Traceback (most recent call last):  ...  DesiredException: ...

Probably useful ... unless /me want to match something inside the error message (which seems very hard to specify if error messages change from time to time )

I'd like to see doctests be able to enable the ELLIPSIS option internally and globally (currently it can only be enabled outside the doctest, or for a single line).

Depending on what you mean when you mention «internally and globally» , you could do such kinds of things with dutest too

* Another option might be something version-specific, like:  >>> throwanexception() # +python<2.7_  _... old exception ..._  _>>> throwanexception() # +python>=2.7  ... new exception ...

You mean skip LOCs if python version is not «compatible» with the one specified in the doctests (e.g. # +python>=2.7) ?

Maybe for instance "# pyversion(less=2.7)" [...]

Or, maybe checkers could be extended so they could actually suppress the execution of code (avoiding throwanexception() from being called twice).

Ah ! Just what I thought !

IMO that choice should be made explicit in the test code but once again doctest does not support something like

{{{

_if sys.versioninfo[:3] <= (2, 7) :_ ... throw_an_exception()   ... else : ... throw_an_exception() # +python>=2.7 ...   }}}

I'd definitely prefer something like that or like what you've mentioned before (i.e. # +python<2.7) but the idea needs to be refined ;o)

To be more explicit, the main limitation is that you cannot make assertions for individual statements inside blocks (e.g. if, for , ...) mainly because that's not how interactive sessions look like

;o)

* Maybe slightly more general, would be the ability to extend OutputCheckers more easily than currently.

You can definitely play with these kind of things (e.g. change OutputCheckers at runtime ;o) by using dutest ;o)

* Or, something more explicit than ELLIPSIS but able also be more flexible than currently possible, like:  >>> throwanexception()  Traceback (most recent call last):  ...  DesiredException: [[2.6 error message | 2.7 error message]]

IMO, this would be limited to be used only with tracebacks, and ellipsis are more general than that (match against anything) My preferences above.

PS: Sorry for the commercials . I'm just mentioning that there's something out there that enhances doctest to support some features you mentioned , that was proposed some time ago to be included in stdlib [3]_ and (at least in theory) is waiting for assessment &| approval . That time the main stopper was its recent release [1]_ , now it has about (184 + 60 + 117 = 361 downloads from PyPI ;o) [2]_ ...

.. [3] [Python-Dev] An OO API for doctest / unittest integration... (http://mail.python.org/pipermail/python-dev/2008-August/081761.html)

.. [1] [Python-Dev] An OO API for doctest / unittest integration... (http://mail.python.org/pipermail/python-dev/2008-August/081762.html)

.. [2] Download dutest @ PyPI (http://pypi.python.org/pypi/dutest)

-- Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/

Featured article: Depurando errores en aplicaciones web CGI con Python - http://feedproxy.google.com/r/simelo-es/3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html

More information about the Python-Dev mailing list