All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
	Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()
Date: Wed, 20 Mar 2013 14:58:45 -0400	[thread overview]
Message-ID: <20130320185844.GB30165@sigill.intra.peff.net> (raw)
In-Reply-To: <20130320184157.GO3655@google.com>

On Wed, Mar 20, 2013 at 11:41:57AM -0700, Jonathan Nieder wrote:

> Ramkumar Ramachandra wrote:
> > Jonathan Nieder wrote:
> 
> >> I dunno.  The helper functions at the top of this test are already
> >> intimidating, so I guess I am looking for a way to avoid making that
> >> problem worse.
> [...]
> > My patch does not make the situation worse in any way:
> 
> Um, yes it does.  It adds another function to learn to an already
> intimidating list.

Personally I do not find the set of helper functions intimidating. I
tend to read the tests in a top-down manner: a test is interesting
(usually because it fails), and then I want to see what it is doing, so
I look at any functions it calls, and so forth.

What I usually find _much_ harder to debug is when there is hidden state
leftover from other tests. So even though it is longer to write, I would
much rather see:

  test_expect_success 'check that frob only affects foo' '
          set_state_of foo &&
          set_state_of bar &&
          git frob &&
          check_state_of foo &&
          check_state_of bar
  '

than for the test to assume the state of "foo" or "bar" prior to the
test. And I think helper functions can help make writing those sorts of
pre-conditions more reasonable (and without looking too hard, I think
t5516 does an OK job of that).

Related to that is when the helper functions operate on hidden state. In
this instance, we have tests that do things like:

    mk_empty &&
    git push testrepo refs/heads/master:refs/remotes/origin/master

and as a reader I say "wait, what's in testrepo?". I can follow mk_empty
and see that it hardcodes testrepo, but it is even better if the
function and its arguments are named in a way that I don't have to. So
even though it is more typing, I would argue that:

  mk_empty testrepo &&
  git push testrepo ...

is better, because the test script is more readable as a unit.

None of this is that huge a deal to me (and yet I seem to have written a
page about it :) ), but I figure while we are bikeshedding about test
style...

-Peff

  reply	other threads:[~2013-03-20 18:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 12:44 [PATCH v2 0/6] Support triangular workflows Ramkumar Ramachandra
2013-03-20 12:44 ` [PATCH 1/6] remote.c: simplify a bit of code using git_config_string() Ramkumar Ramachandra
2013-03-20 18:07   ` Jonathan Nieder
2013-03-20 18:12     ` Ramkumar Ramachandra
2013-03-20 12:44 ` [PATCH 2/6] t5516 (fetch-push): update test description Ramkumar Ramachandra
2013-03-20 18:22   ` Jonathan Nieder
2013-03-20 18:33     ` Ramkumar Ramachandra
2013-03-20 18:35       ` Jonathan Nieder
2013-03-20 12:44 ` [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name() Ramkumar Ramachandra
2013-03-20 18:28   ` Jonathan Nieder
2013-03-20 18:38     ` Ramkumar Ramachandra
2013-03-20 18:41       ` Jonathan Nieder
2013-03-20 18:58         ` Jeff King [this message]
2013-03-20 19:52           ` Junio C Hamano
2013-03-20 20:00           ` Jonathan Nieder
2013-03-20 12:44 ` [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push Ramkumar Ramachandra
2013-03-20 18:30   ` Jonathan Nieder
2013-03-20 19:03   ` Junio C Hamano
2013-03-20 19:43     ` Ramkumar Ramachandra
2013-03-20 19:48       ` Junio C Hamano
2013-03-20 12:45 ` [PATCH 5/6] remote.c: introduce remote.pushdefault Ramkumar Ramachandra
2013-03-20 18:32   ` Jonathan Nieder
2013-03-20 18:53     ` Junio C Hamano
2013-03-20 19:46     ` Ramkumar Ramachandra
2013-03-20 12:45 ` [PATCH 6/6] remote.c: introduce branch.<name>.pushremote Ramkumar Ramachandra
2013-03-20 13:03   ` Tay Ray Chuan
2013-03-20 13:35     ` Ramkumar Ramachandra
2013-03-20 13:06 ` [PATCH v2 0/6] Support triangular workflows Tay Ray Chuan
2013-03-22  7:44   ` Ramkumar Ramachandra
2013-03-20 23:04 ` Philip Oakley
2013-03-22  7:41   ` Ramkumar Ramachandra
2013-03-22 15:16   ` Junio C Hamano
2013-03-23 12:42     ` Ramkumar Ramachandra
2013-03-22  7:52 [PATCH v3 " Ramkumar Ramachandra
2013-03-22  7:52 ` [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name() Ramkumar Ramachandra
2013-03-22 14:44   ` Jeff King
2013-03-22 14:52     ` Junio C Hamano
2013-03-22 14:59       ` Jeff King
2013-03-22 21:14       ` Jonathan Nieder
2013-03-28 13:03     ` Ramkumar Ramachandra
2013-03-22 14:54   ` Junio C Hamano
2013-03-22 14:58     ` Jeff King

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=20130320185844.GB30165@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=sunshine@sunshineco.com \
    /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.