Re: [PATCH v3 1/2] ref-filter: add multiple-option parsing functions

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 20, 2023, 20:30 UTC
Message-ID: <xmqqzg3q1g2y.fsf@gitster.g>
In-Reply-To: <kl6lzg3qzdhn.fsf@chooglen-macbookpro.roam.corp.google.com>

Glen Choo <chooglen@google.com> writes:

Show 8 quoted lines

>> 	So whatever framework we choose, it should allow adding a
>> 	test or two to this patch easily, without being too
>> 	intrusive.  Would that be a good and concrete evaluation
>> 	criterion?
>
> Perhaps, but the biggest blocker to adding a unit tests is whether the
> source file itself is amenable to being unit tested (e.g. does it depend
> on global state? does it compile easily?).

Perhaps.

Now would this particular example, the change to ref-filter.c file, be a reasonable guinea-pig test case for candidate test frameworks to add tests for these two helper functions? They are pretty-much plain vanilla string manipulation functions that does not depend too many things that are specific to Git. They may use helpers we wrote, i.e. xstrndup(), skip_prefix(), and git_parse_maybe_bool(), but they shouldn't depend on the program start-up sequence, discovering repositories, installing at-exit handers, and other stuff. It was why I wondered if it can be used as a good evaluation criterion---if a test framework cannot easily add tests while this patch was being proposed in a non-intrusive way to demonstrate how these two functions are supposed to work and to protect their implementations from future breakage, it would not be all that useful, I would imagine.