On 3/3/2014 3:26 PM, Junio C Hamano wrote:
Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
On Mon, Mar 3, 2014 at 5:24 AM, Ilya Bobyr <ilya.bobyr@xxxxxxxxx> wrote:
This is a counterpart to GIT_SKIP_TESTS. Mostly useful when debugging.
To be grammatically similar to GIT_SKIP_TESTS, perhaps name it GIT_RUN_TESTS?
I actually do not like the interface to use two variables very much.
Can't we just allow negative entries on "to be skipped" list?
That is
GIT_SKIP_TESTS='t9??? !t91??'
would skip nine-thousand series, but would run 91xx series, and all
the others are not excluded.
Simple rules to consider:
- If the list consists of _only_ negated patterns, pretend that
there is "unless otherwise specified with negatives, skip all
tests", i.e. treat GIT_SKIP_TESTS='!t91??' just the same way you
would treat GIT_SKIP_TESTS='* !t91??'.
- The orders should not matter for simplicity of the semantics;
before running each test, check if it matches any negative (and
run it if it matches, without looking at any positives), and
otherwise check if it matches any positive (and skip it if it
does not).
Hmm?
I can do that. But I am not sure that matches the use cases I had in
mind the best.
First use case is that while developing I want to run tests frequently
and I have a specific test that I am working on at the moment.
That test is broken and I am trying to fix it (TDD).
I want to run just the initialization test(s) and then that specific test.
Running everything is quite slow.
GIT_RUN_ONLY addresses the TDD case.
Second case is when I broke one or more tests and want to figure out
what is wrong.
In this case running tests after the broken one will clutter the output
directory and will make debugging somewhat harder, especially if I am
not familiar with all the tests.
For the second case I was actually thinking that something like
"<t9100.32" would be useful, where 32 is the broken test.
Maybe we can come up with an interface that covers all 3 cases?
While exclusion can be used it adds an extra step to both cases, as you
need to mentally negate what you want first.
It might be that we are looking at different use cases, as you are
talking about whole test suits.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html