[PATCH 2 of 3] run-tests: support multiple cases in .t test

[Yuya Nishihara]

On Tue, 2 May 2017 19:01:26 -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu <quark at fb.com>
> # Date 1493488388 25200
> #      Sat Apr 29 10:53:08 2017 -0700
> # Node ID 6663e696ae0c2a1b8f6fd735dfcf9b99fb4dac73
> # Parent  f32a5c7a590fd5d8a9d6c8195b6171331ec9f3a8
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #              hg pull https://bitbucket.org/quark-zju/hg-draft -r 6663e696ae0c
> run-tests: support multiple cases in .t test

The idea sounds nice, and the implementation generally looks good to me.
Can you send V2?

> For example, if a test should behave the same with or without an
> experimental flag, we can add the following to the .t header:
> 
>     #case default
>        ....
>     #case experimental-a
>       $ cat >> $HGRCPATH << EOF
>       > [experimental]
>       > feature=a
>       > EOF
>     #endcase

So this is a sort of parameterized tests? I thought "#case" would be just a
syntactic sugar of "#if"s.

Another idea is to define a set of "cases" beforehand, and use the existing
"#if" syntax, but I'm not sure which is better.

 #variants default experimental-a

 #if default
   ...
 #endif

> +                    tests += [{'path': t, 'case': c} for c in sorted(cases)]
> +            else:
> +                tests.append({'path': t})

Instead of extending the test key to a dict, maybe TestRunner._gettest() could
return a list of all cases? If that works, the key handling will get slightly
simpler.

> +  > #case C
> +  >   $ [ $V == C ]
> +  > #case A
> +  >   $ [ $V == C ]
> +  >   [1]
> +  > #case A B
> +  >   $ [ $V == C ]
> +  >   [1]
> +  > #endcase
> +  >   $ [ $V == D ]

Nit '==' is Bashism. Use '='.