[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