[PATCH 2 of 4] run-tests: allow to put conditions and comments in expected output

Simon Heimberg simohe at besonet.ch
Mon Feb 10 09:46:09 CST 2014


Shortly: Right, this series is not yet ready. At least a small change is 
necessary.
Details below

Am 04.02.2014 16:42, schrieb Mads Kiilerich:
> On 02/04/2014 01:14 AM, Simon Heimberg wrote:
>> # HG changeset patch
>> # User Simon Heimberg <simohe at besonet.ch>
>> # Date 1391470011 -3600
>> #      Tue Feb 04 00:26:51 2014 +0100
>> # Branch stable
>> # Node ID 94c2bb6ad0656684bdc90bb52a1a205a5ad151e3
>> # Parent  ab6f4d067f28326dfdd5c352491c92148f0ee160
>> run-tests: allow to put conditions and comments in expected output
> ...
>> It must be written like this:
>>    $ echo output; false
>> #if true
>>    output
>>    [1]
>> #else
>>    something else
>>    [1]
>> #endif
>
> What will happen when using -i ?
>
> Currently the command and its output is obvious, and -i should just do 
> the right thing in the "code" path that is tested.
>
> How will it work with this new conditional style?

"run-tests.py -i " still behaves nicely when lines have changed. (And of 
course also on any changes on commands outside of a conditional bloc run 
nicely.)

There are some problems when lines are inserted or deleted. They are the 
same kind as when matching (glob/re) is used. See at end of [1] for a 
diff output difficult to read because glob is not matching on the 
expected line. Matching and mixed conditions currently depend on fix 
line numbers. This could probably be improved generally.

example:
   $ printf $DEMO
   l1
   #if true
   l2
   l3
   #else
   L2
   L3
   #endif
   l4
   $ echo xx
   xx

When there is a line before l1, the conditions are moved up by 1 like this:
example:
   $ printf $DEMO
   l0_new
   #if true
   l1
   l2
   #else
   L2
   L3
   #endif
   l3
   $ echo xx
   l4
   xx


Of course l4 may not be moved after the next command. This can be fixed 
by moving one line. Then l4 is directly after l3. The test would run 
smoothly after "-i" and accepting, as long as the condition is the same. 
So the test needs manual editing. Inserting some empty lines or deleting 
some lines will do the trick to let "-i" do the right thing.
(Manual editing is also necessary also when this test would be written 
with the command repeated in the conditional part. The suite will never 
be able to rewrite a non active case.)


Will this behaviour be good enough?


[1] 
http://www.selenic.com/pipermail/mercurial-devel/2014-January/055771.html

>
> If "not so well": Is the increased complexity and maintenance overhead 
> worth it?
>
> For the file://drive/path handling: Wouldn't it be simpler to add a 
> replacement hack to run-tests?

I do not know what a replacement hack is, sorry.

There are for sure different methods for matching. I suggested some in a 
mail [2].
My (new) favorite of them is to match the 3rd "/" by a "*":
    large: largefile 7f7097b041ccf68cc5561e9600da4655d21c6d18 not 
available from file:/*/$TESTTMP/mirror (glob)
instead of
    large: largefile 7f7097b041ccf68cc5561e9600da4655d21c6d18 not 
available from file://$TESTTMP/mirror (glob)
The match is not exact, it would match any number of any character 
between / and /. But this will probably never happen.
I will send this first for fixing the test failures on windows. This 
case inspired the idea for this patch series, but it is not the main use 
case. Less duplicate code as shown in patch 3 is more important.


[2] 
http://www.selenic.com/pipermail/mercurial-devel/2014-January/055770.html

>
> /Mads



More information about the Mercurial-devel mailing list