[RFC] change test output to subunit when stdout is a pipe
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?
More information about the bazaar