[PATCH 0 of 5] Add 'unified' tests to the test framework

[Christian Ebert]

* Nicolas Dumazet on Thursday, August 12, 2010 at 17:07:46 +0900
> On Tue, 03 Aug 2010 11:13:17 -0500
> Matt Mackall <mpm at selenic.com> wrote:
>> On Tue, 2010-08-03 at 08:56 +0200, Dirkjan Ochtman wrote:
>>> On Tue, Aug 3, 2010 at 07:15, Matt Mackall <mpm at selenic.com> wrote:
>>>> This is an experiment in unifying test commands and results as
>>>> discussed at the 1.5 sprint. See the last three patches for what tests
>>>> look like in this model. It's quite an improvement. And when something
>>>> breaks, you get to see the changed output in the context of the
>>>> commands that caused it. Also, there's some basic support for
>>>> filtering of output with regexes, like this:
>>>> 
>>>> Strip 1: expose an old head:
>>>> 
>>>> $ hg --config extensions.mq= strip 5
>>>> saved backup bundle to .*

Nice. Will have to find out what "basic" means.

>>>> ..which means a lot of the hoops tests jump through right now with sed
>>>> and grep are no longer needed.
>>> 
>>> It looks very nice! Definitely something I'd use in other projects as well.
>>> 
>>> One thing that I think could be better is the need for indentation
>>> before $ hg command. I understand that we need something to
>>> disambiguate comments from command output, but I feel that doing it
>>> the other way around would be better (prefix the comments, not the
>>> output). Primarily because I think it's easier to cut-and-paste
>>> command output that way, and we probably have more command output than
>>> comments anyway.
>> 
>> There's not much need to cut and paste command output though. You simply
>> write the test without output, then run it, and you end up with the
>> unified result in .err. And you either copy that over, or use -i to let
>> run-tests do it for you. In other words, just like you'd write a normal
>> test.
> 
> I just pushed a few converted tests. The new format is definitely an
> improvement. I had to debug a few mistakes of mine, and working with
> tests just got much more efficient... Really, just give it a try, folks ;)

Yeah, really kewl ;-) working on test-keyword here. 

>>> We could prefix comments with something like # or %.
>>> I guess that introduces a chance of ambiguity for output starting with
>>> # or %, but we could mitigate that by having a longer prefix, perhaps?
>>> (e.g. %%, although I think % is sufficiently rare in our test output
>>> and/or should be easy to prevent in most cases).
> 
> I'm happy with the current format. Your editor should not have much troubles
> catching up with identation after the first "  $ " line. And it feels
> really natural, as it's close to the syntax you usually use to describe
> shellscript and output in bugtracker/pastebin/...

I see quite a lot of trailing whitespace, e.g. on empty lines,
in the new *.t files, ahem, <duck>

c
-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org/
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions