[py-dev] running doctest-based tests

Max Ischenko ischenko at gmail.com
Thu Jun 9 12:27:18 CEST 2005


> However, item.run() methods currently doesn't have direct means to 
> control output in case of a test failure.  What we should do, i guess, 
> is to say that an explicit 'py.test.skip()' doesn't print any 
> traceback (maybe controlable by some command-line argument). Instead 
> it prints only the given message.  You could then extend your doctest 
> approach to produce the message you want py.test to show.

After studying the code I found out that the way failures are reported is
hardcoded in repr_failure method in TerminalSession. Even tkinter backend
uses it.

My situation requires a custom representation of a failure instead of plain
traceback.

A solution might be to abstract the way failures are reported by moving this
responsibility from TerminalSession to the Failure class, for example. After
all, this even seems logical - different kind of failures may require
different representations and a Failure class is a natural place to hold
this information.  OTOH, the session classes *are* responsible for an actual
failure's representation: be it console output, graphical window or network
socket.

A method to the Failure class will be added that will return a suitable
string representation of a failure. Failure class itself will provide
default implementation that will yield formatted traceback.  This way I
could subclass Failure that will yield doctest output instead of traceback. 

What would you say?




More information about the Pytest-dev mailing list