Re: [RFC PATCH 2/4] test-tool run-command testsuite: support unit tests
- From
Josh Steadmon <steadmon@google.com>
- Date
- Feb 1, 2024, 23:14 UTC
- Message-ID
- <ZbwlzPWVtYuXy8rY@google.com>
- In-Reply-To
- <Zbwki_Dk2hGRce6Y@google.com>
On 2024.02.01 15:08, Josh Steadmon wrote:
Show 30 quoted lines
> On 2024.01.16 15:18, Junio C Hamano wrote: > > Josh Steadmon <steadmon@google.com> writes: > > > Second "--(no-)require-shell-test-pattern" bypasses the check that the > > > test filenames match the expected t####-*.sh pattern. > > > > This one I am not so sure. Do we still have situations where > > erroring out when fed a non t[0-9][0-9][0-9][0-9]-*.sh script is > > problematic? IOW, do we need to keep it as conditional? > > > > ... goes and looks ... > > > > Ah, this variable/option is misnamed and that is what invited the > > above nonsense question out of me. The logic this option disables > > does not "require" (and error out if the requirement is not met); it > > is used in a loop over "ls *" and "filtering" files out that are not > > the numbered scripts. > > > > But that confusion makes me wonder if non-script side of tests would > > also want some filtering in the longer run, even if the directory we > > feed to "test-tool run" happens to contain nothing but what we want > > to run right now. I wonder if we instead want a variable that holds > > a pattern used to match programs readdir() discovers and skip those > > that do not match the pattern? Its default value may be something > > like "t[0-9][0-9][0-9][0-9]-*.sh" but alternatively you can give, > > say, "*" to pass everything, or something like that. > > The original implementation and this series both still allow passing > additional patterns on the command line. Only tests matching the > hardcoded t[0-9][0-9][0-9][0-9]-*.sh pattern plus all the command-line > patterns will be run. The new flag just bypasses the hardcoded pattern.
Actually, I misspoke here. The test must match the hardcoded pattern plus at least one of the command-line patterns (if any were provided).
> Given that V2 will already be changing in non-backwards-compatible ways, > I think it makes the most sense to just delete the hardcoded pattern and > require callers to provide it if they want it.
Given that it sounds like the testsuite functionality is not really used at the moment, I still feel OK with changing the pattern matching logic here for V2.