Pablo Sabater [off-list ref] writes:

Replace old style 'test -f' and 'test -d' with helpers
'test_path_is_file' and 'test_path_is_dir' respectively,
which make debugging a failing test easier by loudly
reporting what expectation was not met.

Well explained.

The instances were found with:

	git grep "test -[efd]" t/

People seem to add the above to their test-path helper patches, but
unless the coverage of the work is fairly thorough and you want to
say "all the similar issues should be found with this command and I
addressed all of them", I do not see much point saying how you found
one of them and addressed it.

You could have used "git grep -e <pattern> -- t/\*.sh", or you could
have been working to fix something in t9200 and noticed these while
you were doing something else to the file.

I do not see it as too huge a deal and it is probably not a cause to
send in another iteration once it is already written, though.

Our test-path helpers should work even outside test_expect_*
functions, so this is not wrong per-se, but it somehow looks a bit
unusual.  A related clean-up would be to wrap the CVS initialization
part inside another "do we even have a working CVS installation to
make it worth our time testing 'git cvsexportcommit' command?"
check, i.e.,

	if ! cvs init || ! test -d "$CVSROOT" || ! cvs -Q co -d "$CVSWORK" .
        then
		skip_all="cvs repository set-up fails"
		test_done
	fi

and then move the git initialization part to its own test, e.g.,

	test_expect_success 'git setup' '
		echo >empty &&
		git add empty &&
		git commit -q -a -m Initial
	'

OK.

 
 # the state of the CVS sandbox may be indeterminate for ' space'