Failing tests print traceback, log, and all twice

Bug #625597 reported by Martin Packman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
In Progress
Low
Unassigned

Bug Description

Since selftest has depended on testtools, the full details of every failing test are printed to the console twice.

The way this used to work was that during the run, when a test failed it would print the exception instance, generally the contents AssertionError on one snappy line. Then, at the end of the run, a full traceback and log would be printed for every test that failed.

However, due to bug 501169 in testtools, rather than getting the actual exception that caused the problem, bzr now gets a _StringException instance. When str is called on that, rather than getting just the exception text, the entire testtools details object is stringified. Which is also what happens at the end of the run.

Related branches

Revision history for this message
Martin Packman (gz) wrote :
Revision history for this message
Martin Packman (gz) wrote :
Changed in bzr:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 625597] [NEW] Failing tests print traceback, log, and all twice

I don't think that that bug is the cause; the cause is almost
certainly a non-upgraded TestResult API method in bzrlib.

Revision history for this message
Martin Packman (gz) wrote :

Well, it's the reason that printing the err parameter doesn't do what it used to. Also means there's no easy way of getting back the actual exception instance, will need addOnException and a dance to get back the old behaviour.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 625597] Re: Failing tests print traceback, log, and all twice

On Mon, Aug 30, 2010 at 2:56 AM, Martin [gz] <email address hidden> wrote:
> Well, it's the reason that printing the err parameter doesn't do what it
> used to. Also means there's no easy way of getting back the actual
> exception instance, will need addOnException and a dance to get back the
> old behaviour.

Why not just grab the last line of the traceback? Or is that not it.
Anyway, as per that bug I'm happy to provide a way to pass the info in
on the traceback content objects.

-Rob

Martin Pool (mbp)
Changed in bzr:
status: Confirmed → In Progress
assignee: nobody → Martin Pool (mbp)
Revision history for this message
Vincent Ladeuil (vila) wrote :

@poolie: didn't you land something related ?

Revision history for this message
Martin Pool (mbp) wrote :

vila, I have https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485 towards this but it's not landed yet.

istr some discussion about wanting an option to get the tracebacks only at the end, but I don't really see a reason you'd want that, and nobody I spoke to said they do want it. So I think I will just print them as they occur; there's always subunit if you want more detailed output.

Revision history for this message
Vincent Ladeuil (vila) wrote :

/me nods @ poolie and thanks for the status report

I can't find a good reason to get the tracebacks at the end *only* and yes, subunit seems to be the best route for details.

Martin Pool (mbp)
Changed in bzr:
assignee: Martin Pool (mbp) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.