Re: [PATCH 2/4] t5310: test delta reuse with bitmaps

From: Ben Peart <peartben@gmail.com>
Date: Sep 1, 2018, 22:46 UTC
Message-ID: <ececf0e9-f569-dd07-9ab1-dc65ebb0a814@gmail.com>
In-Reply-To: <87va7parmi.fsf@evledraar.gmail.com>

On 9/1/2018 4:29 PM, Ævar Arnfjörð Bjarmason wrote:

Show 15 quoted lines

> 
> 
> B.t.w. for Ben or anyone else who knows about the fsmonitor part of
> this: I've long been running the whole test suite with
> `GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all prove ...` (also along with
> GIT_TEST_SPLIT_INDEX=) after all the main tests pass as additional
> stress testing.
> 
> It's not documented under the "special setups" section. So I was going
> to add it, but I see that in 5c8cdcfd80 ("fsmonitor: add test cases for
> fsmonitor extension", 2017-09-22) it's documented that you should also
> set GIT_FORCE_PRELOAD_TEST=true, is that needed for GIT_FSMONITOR_TEST?
> Or is it yet another mode, and if so to be combined with fsmonitor in
> particular, or stand-alone?
>

I was unaware of the "special setups" section until recently so if you would add the fsmonitor information that would be great.

I added the GIT_FORCE_PRELOAD_TEST as when I went to test fsmonitor I realized there was no way to manually override the default behavior and force preload to happen. I added tests into t7519-status-fsmonitor.sh that use this capability to test fsmonitor with and without preload to ensure they play nice together as I had to add logic into the preload code to mark cache entries as clean for fsmonitor.

GIT_FORCE_PRELOAD_TEST should probably be added to the "special setups" as well so that the entire test suite can be used to exercise that code path.

Ultimately, GIT_FSMONITOR_TEST and GIT_FORCE_PRELOAD_TEST can be used to test their respective code paths using the test suite. The challenge is that the number of potential combinations (including split index, uncommon pack modes, etc) gets large pretty quickly.

Show 8 quoted lines

>> There may be a larger lesson about tracking code coverage, but I don't
>> know that most general code coverage tools would have helped (any
>> overall percentage number would be too large to move). A tool that
>> looked at the diff and said "of the N lines you added/touched, this
>> percent is exercised in the test suite" might have been useful.
> 
> This would be very useful.
>