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?). 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.
