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

Yuya Nishihara yuya at tcha.org
Tue May 16 09:17:18 EDT 2017


On Mon, 15 May 2017 08:18:22 -0700, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-05-15 22:42:02 +0900:
> > [...] 
> > 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.
> 
> This feels like implicitly vs explicitly defining a variable. The former
> saves several lines (#endif). The latter makes it harder to make mistakes.
> 
> It'd be nice if "#if" could support logic operations like "#if a | (b & c)".
> Then "#if" could be more powerful.
> 
> Since "#if" could be made more powerful in the future, I'll change the code
> to use "#if".
> 
> >  #variants default experimental-a
> >
> >  #if default
> >    ...
> >  #endif
> 
> Implementation detail: Maybe "#testcases" is easier to understand.

Yeah, it sounds better.

> run-tests.py exports "$HGTESTCASE" so hghave.py could read it.

TTest has in-process _hghave() function, which would probably be hooked.

> > > +                    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.
> 
> _gettest is also used by _reloadtest which is intended to reload and return
> a single test. We need bi-directional conversion between test instance and
> its description dict to make _reloadtest work.
> 
> A future feature I was considering is to allow specifying which case to run,
> like "run-tests.py a.t:case-a". It might be cleaner to be implemented in
> "findtests" since findtests is the only place parsing non-config arguments.

Fair enough. Then, using a namedtuple might slightly improve the code
readability. It wasn't easy to read whether the "test" variable is a test
object or a dict.


More information about the Mercurial-devel mailing list