On 9/1/2018 4:29 PM, Ævar Arnfjörð Bjarmason wrote:
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.
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.
