git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stephan Beyer <s-beyer@gmx.net>
Cc: git@vger.kernel.org, Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH v2 03/21] t/test-lib-functions.sh: generalize test_cmp_rev
Date: Fri, 15 Apr 2016 13:00:13 -0700	[thread overview]
Message-ID: <xmqqd1pqbq2a.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1460294354-7031-4-git-send-email-s-beyer@gmx.net> (Stephan Beyer's message of "Sun, 10 Apr 2016 15:18:56 +0200")

Stephan Beyer <s-beyer@gmx.net> writes:

> test_cmp_rev() took exactly two parameters, the expected revision
> and the revision to test. This commit generalizes this function
> such that it takes any number of at least two revisions: the
> expected one and a list of actual ones. The function returns true
> if and only if at least one actual revision coincides with the
> expected revision.

There may be cases where you want to find the expected one among
various things you actually have (which is what the above talks
about; it is like "list-what-I-actually-got | grep what-i-want"),
but an equally useful use case would be "I would get only one
outcome from test, I anticipate one of these things, all of which is
OK, but I cannot dictate which one of them should come out" (it is
like "list-what-I-can-accept | grep what-I-actually-got").

I am not enthused by the new test that implements the "match one
against multi" check only in one way among these possible two to
squat on a very generic name, test_cmp_rev.

The above _may_ appear a non-issue until you realize one thing that
is there to help those who debug the tests, which is ...

> While at it, the side effect of generating two (temporary) files
> is removed.

That is not strictly a side effect.  test_cmp allows you to see what
was expected and what you actually had when the test failed (we
always compare expect with actual and not the other way around, so
that "diff -u expect actual" would show how the actual behaviour
diverted from our expectation in a natural way).

Something with the semantics of these two:

	test_revs_have_expected () {
        	expect=$1
		shift
		git rev-parse "$@" | grep -e "$expect" >/dev/null && return
		echo >&2 "The expected '$1' is not found in:"
                printf >&2 " '%s'\n", "$@"
                return 1
	}

	test_rev_among_expected () {
		actual=$1
                shift
		git rev-parse "$@" | grep -e "$actual" >/dev/null && return
		echo >&2 "'$1' is not among expected ones:"
                printf >&2 " '%s'\n", "$@"
                return 1
	}

might be more appropriate.

>
> Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
> ---
>  t/test-lib-functions.sh | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 8d99eb3..8caf59c 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -711,11 +711,17 @@ test_must_be_empty () {
>  	fi
>  }
>  
> -# Tests that its two parameters refer to the same revision
> +# Tests that the first parameter refers to the same revision
> +# of at least one other parameter
>  test_cmp_rev () {
> -	git rev-parse --verify "$1" >expect.rev &&
> -	git rev-parse --verify "$2" >actual.rev &&
> -	test_cmp expect.rev actual.rev
> +	hash1="$(git rev-parse --verify "$1")" || return
> +	shift
> +	for rev
> +	do
> +		hash2="$(git rev-parse --verify "$rev")" || return
> +		test "$hash1" = "$hash2" && return 0
> +	done
> +	return 1
>  }
>  
>  # Print a sequence of numbers or letters in increasing order.  This is

  parent reply	other threads:[~2016-04-15 20:00 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-10 13:18 [PATCH v2 00/21] git bisect improvements Stephan Beyer
2016-04-10 13:18 ` [PATCH v2 01/21] bisect: write about `bisect next` in documentation Stephan Beyer
2016-04-10 13:18 ` [PATCH v2 02/21] bisect: allow 'bisect run' if no good commit is known Stephan Beyer
2016-04-10 13:18 ` [PATCH v2 03/21] t/test-lib-functions.sh: generalize test_cmp_rev Stephan Beyer
2016-04-11  0:07   ` Eric Sunshine
2016-04-15 20:00   ` Junio C Hamano [this message]
2016-04-24 19:51     ` Stephan Beyer
2016-04-25 18:08       ` Junio C Hamano
2016-04-10 13:18 ` [PATCH v2 04/21] t: use test_cmp_rev() where appropriate Stephan Beyer
2016-04-11  0:07   ` Eric Sunshine
2016-04-15 20:48   ` Junio C Hamano
2016-04-10 13:18 ` [PATCH v2 05/21] t6030: generalize test to not rely on current implementation Stephan Beyer
2016-04-10 13:47   ` Torsten Bögershausen
2016-04-10 19:16     ` Junio C Hamano
2016-04-10 19:37       ` Stephan Beyer
2016-04-11  0:23     ` Eric Sunshine
2016-04-15 21:07   ` Junio C Hamano
2016-04-10 13:18 ` [PATCH v2 06/21] bisect: add test for the bisect algorithm Stephan Beyer
2016-04-15 21:13   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 07/21] bisect: plug the biggest memory leak Stephan Beyer
2016-04-15 21:18   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 08/21] bisect: make bisect compile if DEBUG_BISECT is set Stephan Beyer
2016-04-15 21:22   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 09/21] bisect: make algorithm behavior independent of DEBUG_BISECT Stephan Beyer
2016-04-15 21:25   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 10/21] bisect: get rid of recursion in count_distance() Stephan Beyer
2016-04-15 21:31   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 11/21] bisect: use struct node_data array instead of int array Stephan Beyer
2016-04-12 23:02   ` Christian Couder
2016-04-15 21:47   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 12/21] bisect: replace clear_distance() by unique markers Stephan Beyer
2016-04-12 23:20   ` Christian Couder
2016-04-15 22:07   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 13/21] bisect: use commit instead of commit list as arguments when appropriate Stephan Beyer
2016-04-15 22:08   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 14/21] bisect: extract get_distance() function from code duplication Stephan Beyer
2016-04-15 22:08   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 15/21] bisect: introduce distance_direction() Stephan Beyer
2016-04-15 22:10   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 16/21] bisect: make total number of commits global Stephan Beyer
2016-04-13 13:23   ` Christian Couder
2016-04-15 22:11   ` Junio C Hamano
2016-04-16  0:44   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 17/21] bisect: rename count_distance() to compute_weight() Stephan Beyer
2016-04-13 13:32   ` Christian Couder
2016-04-15 22:12   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 18/21] bisect: prepare for different algorithms based on find_all Stephan Beyer
2016-04-15 22:36   ` Junio C Hamano
2016-04-10 13:19 ` [PATCH v2 19/21] bisect: use a bottom-up traversal to find relevant weights Stephan Beyer
2016-04-13 14:11   ` Christian Couder
2016-04-15 22:47   ` Junio C Hamano
2016-04-15 22:49   ` Junio C Hamano
2016-04-26 18:27   ` Junio C Hamano
2016-04-10 13:24 ` [PATCH v2 20/21] bisect: compute best bisection in compute_relevant_weights() Stephan Beyer
2016-04-10 13:24   ` [PATCH v2 21/21] bisect: get back halfway shortcut Stephan Beyer
2016-04-15 22:53     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqd1pqbq2a.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=s-beyer@gmx.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).