Lars Hjemli <hjemli@xxxxxxxxx> writes:
> +# create a submodule repository
> +mkdir lib && cd lib
> +git-init >/dev/null
> +echo a >a && git-add a && git-commit -q -m "submodule commit 1"
> +git-tag -a -m "rev-1" rev-1
> +rev1=$(git-rev-parse HEAD)
> +cd ..
> +
> +# add submodule and other files to super repo
> +echo a >a && echo z >z
> +git-add a lib z && git-commit -q -m "super commit 1"
> +
> +# move submodule to another location, register repo url in .gitmodules
> +mv lib .subrepo
> +GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
We typically try to catch malfunction even while setting up the test case.
> +test_expect_success 'status is "missing"' \
> + 'git-submodule status | grep "^-$rev1"'
> +
> +# make sure 'init' will not overwrite a regular file
> +touch lib
> +test_expect_failure 'init fails when path is used by a file' \
> + 'git-submodule init'
I am guilty for introducing "expect-failure", but it is usually
a mistake to use it unless you are testing something very trivial.
For example, for this case, you would want to make sure the
command "git-submodule init" exits with non-zero status, but
also you would want to make sure that it does not disturb the
existing file "lib". You might also want to see if the command
gives the right error message (or status code) as well, although
typically the wording of error message is subject to change, so
we tend to try not to be too strict about it.
In any case, I would probably write this part of the code like
this:
test_expect_success 'init fails when path is used by a file' '
echo hello >lib &&
if git-submodule init
then
echo "Oops, should have failed"
false
elif test -f lib && test "$(cat lib)" = hello
then
: happy
else
echo "Oops, failed but lib file was molested"
false
fi
'
Later when somebody tries to improve git-submodule and botches,
he can run the test with "-i -v" and observe which "Oops" comes
out to see why the test failed -- it would give him a clue on
how he broke it.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
