Re: [GSoC][PATCH v2] t: migrate t0110-urlmatch-normalization to the new framework

From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Date: Aug 14, 2024, 01:35 UTC
Message-ID: <b369797c-37c0-4f17-b857-a2ff8680cb4f@gmail.com>
In-Reply-To: <xmqqh6bo448j.fsf@gitster.g>

On 14/08/24 00:52, Junio C Hamano wrote:

Show 18 quoted lines

> Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:
>
> I wonder if we should get of t/t-urlmatch-normalization/ directory
> and instead hold these test data in the form of string constants in
> the program.  After all, you have the expected normalization result
> hardcoded in the binary (e.g. t_url_high_bit() asks the checker
> function to read from "url-1" file and then compare the result of
> normalization with a hardcoded string constant), so having the test
> data in separate files only risks the input and the output easily
> drift apart.
> 
> As a side effect, it would make it easily possible to run the tests
> anywhere, because you no longer depend on these url-$n input files.
> It of course depends on how burdensome the limitation that we can
> run the tests only from a fixed place really is, but it generally is
> not a good idea to have these random sequence of bytes in small
> files that nobody looks at in a repository in the first place.
>

I think the reason these inputs are present in the files is solely because they are random sequence of characters which contain unicode and even some control characters. This makes it tricky to hold the input string in the source itself.

I'm not sure there would be a straight-forward way to have these inputs in the C source file. There may be some way to represent them in an alternate form but I suppose that would sacrifice the readability of these inputs which I believe is also a significant factor for test cases.

Feel free to enlighten us if we're possibly missing some straight forward way of having these input URLs in the source files.

-- Sivaraam