git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 03/21] t/test-lib-functions.sh: generalize test_cmp_rev

From
Stephan Beyer <s-beyer@gmx.net>
Date
Apr 24, 2016, 19:51 UTC
Message-ID
<571D23CB.8020305@gmx.net>
In-Reply-To
<xmqqd1pqbq2a.fsf@gitster.mtv.corp.google.com>
Hi,
On 04/15/2016 10:00 PM, Junio C Hamano wrote:
Show 16 quoted lines
> 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 see that these are strictly speaking (slightly) different semantics but in the end it boils down to be the same, or am I missing anything?

Show 15 quoted lines
> 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).

I was referring to *generating the files* as a side effect. I did not even think about the fact that "diff" in the original code does not only return an exit code but that it also generates output that can be used as "helpful diagnostic information" (referring to Eric Sunshine's mail here). I was not aware that the Git tests should -- besides testing -- already include "tools" for easier debugging in case of a failure... So dropping this information was not intentional.

Show 21 quoted lines
> 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.

Ah! That's what I meant above. The code is copy&paste besides variable naming and the output "title". Such code duplication for the sake of "easier debugging" in case of a failure?

Also I wonder if test authors in the future would really know *which* one is the right one to use. In the end, either one of these two will just be used arbitrarily (and I wouldn't even think there's anything bad about it, because it *is* the same logic). I think this distinction is like having two algorithms doing the same but with a different name. Something you do NOT really want.

So I'd vote against a distinction of these two "cases", but I have no problem with re-adding "debug" information (like you did in your code examples).

Thanks! Stephan

Previous: Junio C HamanoNext: Junio C Hamano
Message 7 of 56 in “git bisect improvements”
  1. 00/21 git bisect improvementsStephan Beyer, Apr 10, 2016
  2. 01/21 bisect: write about `bisect next` in documentationStephan Beyer, Apr 10, 2016
  3. 02/21 bisect: allow 'bisect run' if no good commit is knownStephan Beyer, Apr 10, 2016
  4. 03/21 t/test-lib-functions.sh: generalize test_cmp_revStephan Beyer, Apr 10, 2016
  5. Eric SunshineApr 11, 2016
  6. Junio C HamanoApr 15, 2016
  7. Stephan BeyerApr 24, 2016
  8. Junio C HamanoApr 25, 2016
  9. 04/21 t: use test_cmp_rev() where appropriateStephan Beyer, Apr 10, 2016
  10. Eric SunshineApr 11, 2016
  11. Junio C HamanoApr 15, 2016
  12. 05/21 t6030: generalize test to not rely on current implementationStephan Beyer, Apr 10, 2016
  13. Torsten BögershausenApr 10, 2016
  14. Junio C HamanoApr 10, 2016
  15. Stephan BeyerApr 10, 2016
  16. Eric SunshineApr 11, 2016
  17. Junio C HamanoApr 15, 2016
  18. 06/21 bisect: add test for the bisect algorithmStephan Beyer, Apr 10, 2016
  19. Junio C HamanoApr 15, 2016
  20. 07/21 bisect: plug the biggest memory leakStephan Beyer, Apr 10, 2016
  21. Junio C HamanoApr 15, 2016
  22. 08/21 bisect: make bisect compile if DEBUG_BISECT is setStephan Beyer, Apr 10, 2016
  23. Junio C HamanoApr 15, 2016
  24. 09/21 bisect: make algorithm behavior independent of DEBUG_BISECTStephan Beyer, Apr 10, 2016
  25. Junio C HamanoApr 15, 2016
  26. 10/21 bisect: get rid of recursion in count_distance()Stephan Beyer, Apr 10, 2016
  27. Junio C HamanoApr 15, 2016
  28. 11/21 bisect: use struct node_data array instead of int arrayStephan Beyer, Apr 10, 2016
  29. Christian CouderApr 12, 2016
  30. Junio C HamanoApr 15, 2016
  31. 12/21 bisect: replace clear_distance() by unique markersStephan Beyer, Apr 10, 2016
  32. Christian CouderApr 12, 2016
  33. Junio C HamanoApr 15, 2016
  34. 13/21 bisect: use commit instead of commit list as arguments when appropriateStephan Beyer, Apr 10, 2016
  35. Junio C HamanoApr 15, 2016
  36. 14/21 bisect: extract get_distance() function from code duplicationStephan Beyer, Apr 10, 2016
  37. Junio C HamanoApr 15, 2016
  38. 15/21 bisect: introduce distance_direction()Stephan Beyer, Apr 10, 2016
  39. Junio C HamanoApr 15, 2016
  40. 16/21 bisect: make total number of commits globalStephan Beyer, Apr 10, 2016
  41. Christian CouderApr 13, 2016
  42. Junio C HamanoApr 15, 2016
  43. Junio C HamanoApr 16, 2016
  44. 17/21 bisect: rename count_distance() to compute_weight()Stephan Beyer, Apr 10, 2016
  45. Christian CouderApr 13, 2016
  46. Junio C HamanoApr 15, 2016
  47. 18/21 bisect: prepare for different algorithms based on find_allStephan Beyer, Apr 10, 2016
  48. Junio C HamanoApr 15, 2016
  49. 19/21 bisect: use a bottom-up traversal to find relevant weightsStephan Beyer, Apr 10, 2016
  50. Christian CouderApr 13, 2016
  51. Junio C HamanoApr 15, 2016
  52. Junio C HamanoApr 15, 2016
  53. Junio C HamanoApr 26, 2016
  54. 20/21 bisect: compute best bisection in compute_relevant_weights()Stephan Beyer, Apr 10, 2016
  55. 21/21 bisect: get back halfway shortcutStephan Beyer, Apr 10, 2016
  56. Junio C HamanoApr 15, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.