[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