Re: [PATCH v2 01/18] t7107, t7526: directly test parse_pathspec_file()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 19, 2019, 06:25 UTC
- Message-ID
- <xmqq5zicde83.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <xmqqwoatcn5u.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> "Alexandr Miloslavskiy via GitGitGadget" <gitgitgadget@gmail.com> > writes: > ... >> 3) Tests are indirect > > That cuts both ways. For a developer who is too narrowly focused > (because s/he spent enough time staring at the code), testing the > underlying machinery in a more direct way does feel attractive, but > at the same time, what matters to the end users is how well the > feature, when integrated into the commands they use (not the test > scaffolding like the "test-parse-pathspec-file" command), works. > > So "indirect" is not necessarily a bad thing.
Just to avoid misunderstanding, I am not opposed to adding tests and test helpers that allows direct access to the guts of the machinery to check the behaviour of the lower level codepath. I am merely saying that such tests would not make it unnecessary to have end-to-end tests that validates end-user visible effects.
Thanks.