All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mike Rappazzo <rappazzo@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
	"Nguyễn Thái Ngọc" <pclouds@gmail.com>,
	"SZEDER Gábor" <szeder@ira.uka.de>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH v3 1/2] rev-parse tests: add tests executed from a subdirectory
Date: Sun, 08 May 2016 11:46:23 -0700	[thread overview]
Message-ID: <xmqq37psz8u8.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqvb2ozapp.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Sun, 08 May 2016 11:05:54 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> What I had in mind was more a long the lines of this change. I only
> did the first several just for illustration (I added an 'exit' to
> mark where I stopped), but I think you get the idea.  The point is
> that by doing things in subprocess inside test_expect_success you
> can avoid disrupting the main test process even when a test fails as
> much as possible, and this illustrates how you would deal with the
> "cd" and "export".  What I didn't handle was the updates to
> .git/config whose effects by earlier tests are relied on later tests
> in this illustration.
>
> As to "table driven" vs "explicitly spelling out scripts, accepting
> some code repetition", I tend to favor the latter slightly, unless
> the table driven approach is done in such a way that each of its
> tests are truly independent from one another, i.e. if a row of the
> table represents one test, the tests would not be disrupted by
> reordering the rows, inserting a new row in the middle, or removing
> an existing row.  From my experience, "table-driven" sets of tests
> whose rows have inter-dependency has been much harder to debug when
> I had to hunt down a bug that manifests itself only in one test in
> the middle.
>
> Hope this helps clarify what I meant.


If you want to go forward in this direction, three are a few
additional things to note.

> +	test_expect_success "$name: is-bare-repository" "
> +	(
> +		$prep &&
> +		test '$1' = \"\$(git rev-parse --is-bare-repository)\"
> +	)"

This is not a new problem, but quoting the test body with dq instead
of sq pair make it ugly to read.  We might want to do something like

	expect=$1
	test_expect_success "$name: is-bare-repository" '
	(
		$prep &&
		test "$outcome" = "$(git rev-parse --is-bare-repository)"
	)'

>  	shift
>  	[ $# -eq 0 ] && return

Also, let's avoid []; i.e.

	test $# = 0 && return

> -# label is-bare is-inside-git is-inside-work prefix git-dir
> +# label prep is-bare is-inside-git is-inside-work prefix git-dir
>  
>  ROOT=$(pwd)
> +mkdir -p sub/dir work

Remember this place in the script, I may refer to it later.

> -git config core.bare true
> -test_rev_parse 'core.bare = true' true false false
> +test_rev_parse subdirectory 'cd sub/dir' \
> +	false false true sub/dir/ "$ROOT/.git"
>  
> -git config --unset core.bare
> -test_rev_parse 'core.bare undefined' false false true
> +test_rev_parse 'core.bare = true' 'git config core.bare true' \
> +	true false false

I didn't use "test_config" and "test_unconfig" here, because you
cannot use them in a subprocess.  If we truly want to make these
tests independent from each other, we'd need to come up with a way
for the tests to revert the configuration state back to where it was
before they started.
>  
> -mkdir work || exit 1
> -cd work || exit 1
> -GIT_DIR=../.git
> -GIT_CONFIG="$(pwd)"/../.git/config
> -export GIT_DIR GIT_CONFIG
>  
> -git config core.bare false
> -test_rev_parse 'GIT_DIR=../.git, core.bare = false' false false true ''
> +test_rev_parse 'GIT_DIR=../.git, core.bare = false' '
> +	cd work && 
> +	GIT_DIR=../.git &&
> +	GIT_CONFIG="$(pwd)"/../.git/config &&
> +	export GIT_DIR GIT_CONFIG &&
> +	git config core.bare false' \
> +	false false true ''

The "prep" step for this test is long and I'd assume that the later
tests would need to do something similar themselves.  To avoid
repetition, create a helper shell function to reduce boilerplate
before the series of these tests start (i.e. the place above) and
call it from the prep parts with different arguments, e.g. making
the above test into

test_rev_parse 'GIT_DIR=../.git, core.bare = false' '
	cd work && 
	set_common_env ../.git false' \
	false false true ''

by having something like

set_dir_and_core_bare () {
	GIT_DIR=$1 &&
	GIT_CONFIG="$(pwd)/$GIT_DIR/config" &&
	export GIT_DIR GIT_CONFIG &&
	git config core.bare "$2"
}

> +exit
>  
>  git config core.bare true
>  test_rev_parse 'GIT_DIR=../.git, core.bare = true' true false false ''

  reply	other threads:[~2016-05-08 18:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06 13:35 [PATCH v3 0/2] [PATCH v3 0/2] rev-parse: fix some options when executed from subpath of main tree Michael Rappazzo
2016-05-06 13:35 ` [PATCH v3 1/2] rev-parse tests: add tests executed from a subdirectory Michael Rappazzo
2016-05-06 22:10   ` Junio C Hamano
2016-05-07 13:35     ` Mike Rappazzo
2016-05-08 18:05       ` Junio C Hamano
2016-05-08 18:46         ` Junio C Hamano [this message]
2016-05-06 13:35 ` [PATCH v3 2/2] rev-parse: fix some options when executed from subpath of main tree Michael Rappazzo
2016-05-10  7:38   ` Eric Sunshine
  -- strict thread matches above, loose matches on Subject: below --
2017-02-10 15:33 [PATCH v2 0/2] Fix bugs in rev-parse's output when run in a subdirectory Johannes Schindelin
2017-02-17 16:58 ` [PATCH v3 " Johannes Schindelin
2017-02-17 16:59   ` [PATCH v3 1/2] rev-parse tests: add tests executed from " Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq37psz8u8.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=rappazzo@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=szeder@ira.uka.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.