Re: [PATCH/RFC] Gitweb: Convert UTF-8 encoded file names

From: Junio C Hamano <gitster@pobox.com>
Date: May 16, 2014, 18:17 UTC
Message-ID: <CAPc5daUzcQvPCY8UQE4-OuNOswKxTMBNTddGV9YWXwONXoV3Qg@mail.gmail.com>
In-Reply-To: <CANQwDwe8Eb+ORiRyuq3+kKw72Jath_DGySmws1Rvt8bmuHoXVw@mail.gmail.com>

(sorry if you receive a dup; pobox.com seems to be constipated right now)

Jakub Narębski <jnareb@gmail.com> writes:

Show 10 quoted lines

>> Correct, but is "where does it appear" the question we are
>> primarily interested in, wrt this breakage and its fix?
>
> That of course depends on how we want to test gitweb output.
> The simplest solution, comparing with known output with perhaps
> fragile / variable elements masked out could be done quickly...
> but changes in output (even if they don't change functionality,
> or don't change visible output) require regenerating test cases
> (expected output) to test against - which might be source of
> errors in test suite.

I agree with your "to test it fully, we need extra dependencies", but my point is that it does not have to be a full "HTML-validating, picking the expected attribute via XPATH matching" kind of test if what we want is only to add a new test to protect this particular fix from future breakages.

For example, I think it is sufficient to grep for 'href="...%xx%xx"' in the output after preparing a sample tree with one entry to show. The expected substring either exists (in which case we got it right), or it doesn't (in which case we are showing garbage). Of course that depends on the assumption that its output is not too heavily contaminated with volatile parts outside our control, as I already mentioned in the message you are responding to.

But it all depends on "if" we wanted to add a new test ;-)