Re: [PATCH 2/2] test-lib: GIT_TEST_ONLY to run only specific tests

[Junio C Hamano <gitster@pobox.com>]

Ilya Bobyr <ilya.bobir@gmail.com> writes:

> While it could be done, it looks less obvious than this:
>
>     GIT_TEST_ONLY='1 4' ./t0001-init.sh

If you are thinking about affecting only one test, then you
shouldn't be mucking with environment variables in the first place,
primarily because running:

    $ GIT_TEST_ONLY='1 4' make test

to run test .1 and .4 of all the test scripts would not make any
sense.  I think your "simplicity" argument is a total red-herring.
Of course if you do not have to say the test script name, your
specification would be shorter, but that is only because your
specification is not specific enough to be useful.

Giving that as a command line argument to the specific script, e.g.

    $ sh ./t0001-init.sh --only='1 4'

might make some sense, but the above GIT_TEST_ONLY does not make any
sense from the UI point of view.

There are many reasons that makes me unenthused about this line of
change in the first place:

 * Both at the philosophical level and at the practical level, I've
   found that it always makes sense to run most of the tests, i.e.
   skipping ought to be an exception not the norm. Over the course
   of this project, I often saw an alleged fix to one part of the
   system introduces breakages that are caught by tests that checks
   parts of the system that does not have any superficial link to it
   (e.g. update the refs code and find a rebase test break).

 * Even though GIT_SKIP_TESTS mechanism still allows you to skip
   individual test pieces, it has never been a serious "feature" in
   the first place. Many of the tests unfortunately do rely on state
   previous sequences of tests left behind, so it is not realistic
   to expect that you can skip test pieces randomly and exercise
   later test pieces reliably.

 * The numbering of individual test pieces can easily change by new
   tests inserted in the middle; again, many tests do take advantge
   of the states earlier tests leave behind, so "do not add new
   tests in the middle" is not a realistic rule to enforce, unless
   you are willing to clean up existing test scripts so that each
   test piece is independent from all the previous ones.

The latter two makes the ability to skip individual test pieces a
"theoretically it could be made useful but practically not so much"
misfeature.  I am very hesitant to see the test framework code
churned only to enhance its "usefulness" when there isn't any in the
first place, without first making changes that fundamentally
improves its usefulness (e.g. to solve "test numbering is not
stable" problem, you could identify the tests with test names
instead of numbers to make it more stable, but that is not what your
patch is even attempting to do).

I view such a change as merely a code churn, damaging the codebase
that is already less nice than ideal and turning it more difficult
to fix properly to make it truly nicer later.

My suggestion to cram everything into GIT_SKIP_TESTS is primarily
because it is one way I can easily see how it allows us to limit the
"damage" to the codebase--the suggested change could be contained
within a single shell function "match_pattern_list" and no other
code has to change to support it.  I am not saying it is the only
way, but glancing at your patch, adding an extra environment
variable would need to also modify its callers, so the extent of the
damage to the codebase seemed somewhat larger.

So, I dunno.  I am not yet enthused.