Junio C Hamano <gitster@xxxxxxxxx> writes: > Glen Choo <chooglen@xxxxxxxxxx> writes: > >>> 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?). > > 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. Ah, yes. This would be close-to-ideal candidate then. > 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. The current thinking among Googlers is that we won't remove the helpers from library code. Git will either provide them, e.g. via Calvin's git-std-lib RFC [1], or we will provide ways for callers to bring their own implementation (like trace2 or exit, since it doesn't necessarily make sense to use Git's implementation). So yes, the test framework should be able to support this sort of compilation pattern. I'm not sure how much test frameworks differ in this regard, maybe Josh has some insight here. [1] https://lore.kernel.org/git/20230627195251.1973421-1-calvinwan@xxxxxxxxxx
