[RFC] change test output to subunit when stdout is a pipe

Martin Pool mbp at sourcefrog.net
Mon Jul 20 08:03:00 BST 2009


2009/7/20 Robert Collins <robertc at robertcollins.net>:
>> At the moment subunit format has an external dependency.  Users run
>> bzr selftests and report the results.  I would think twice before
>> making that harder.  (Though installing one more Python module is not
>> that much harder, so not out of the question.)
>
> We could embed a copy of subunit; its also GPL, and quite small.
>
>> Would it be reasonable to just always use it?  I thought it was meant
>> to be human readable, so would it be reasonable to use subunit format
>> always, or could we use a reasonable variation of it that eg only
>> includes failures?
>
> Human readable and pretty-to-read are different qualities. subunit is
> human readable, but also has metadata that makes it more noisy than our
> current pretty printer. It also is a streaming format so it doesn't do
> the 'summary and then details' separation we do. I'm planning on
> teaching subunit to gather more data as well, which will make using it
> as the default less appealing, I suspect. OTOH, perhaps it would be ok -
> why not give it a go and see what you think?

I used it for the last test run I did and will keep using it as the
default for a while.

The first thing I noticed is that it loses the elapsed time measure.

So far I think on the whole it's not that bad, but it doesn't compare
well to our default.

I can see some cases where redirection into a file rather than on a
terminal should change default behaviour - for instance, from the
recent thread, that it shouldn't show the progress bar.  I think using
an entirely different format seems like too large of a change.  Would
it be enough to just give --subunit a short name?

Is there a larger story around why you're often redirecting the output?

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list