[py-dev] running doctest-based tests

[holger krekel]

On Thu, Jun 09, 2005 at 13:27 +0300, Max Ischenko wrote:
> > 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?

your analysis is pretty correct.  However, my idea was to just let 
py.test.skip(someobj) internally take care that str(someobj) provides
the failure message representation.  Doing that by an internal 
subclass is fine but an implementation detail that should not get 
exposed (Failure classes are not visible directly). 

cheers, 

    holger