git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tao Klerks <tao@klerks.biz>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v3] t3200: fix antipatterns in existing branch tests
Date: Thu, 12 May 2022 07:12:29 +0200	[thread overview]
Message-ID: <CAPMMpogxDfmoc_9CnL6x2Hf79BgWDrq=3KfMrbc+xwyo1k=yJQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqh765mcn0.fsf@gitster.g>

On Wed, May 4, 2022 at 7:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>
> > @@ -510,63 +512,57 @@ test_expect_success 'git branch --copy dumps usage' '
> >  test_expect_success 'git branch -c d e should work' '
> >       git branch --create-reflog d &&
> >       git reflog exists refs/heads/d &&
> > -     git config branch.d.dummy Hello &&
> > +     test_config branch.d.dummy Hello &&
> >       git branch -c d e &&
> >       git reflog exists refs/heads/d &&
> >       git reflog exists refs/heads/e &&
> > -     echo Hello >expect &&
> > -     git config branch.e.dummy >actual &&
> > -     test_cmp expect actual &&
> > -     echo Hello >expect &&
> > -     git config branch.d.dummy >actual &&
> > -     test_cmp expect actual
> > +     test_cmp_config Hello branch.e.dummy &&
> > +     test_cmp_config Hello branch.d.dummy
> >  '
>
> This test used to leave both branch.d.dummy and branch.e.dummy behind
> for later tests.  Now with this patch, we clean branch.d.dummy
> because we use test_config, but branch.e.dummy that was copied by
> successful "git branch -c" will still be left.
>
>  - It is unforunate that it is impossible to verify that the change
>    in behaviour for branch.d.dummy is correct.  Without checking all
>    the remainder of the test (and no, grepping for branch.d.dummy is
>    not "checking all the remainder"---a later "branch -c d x" would
>    have created brnach.x.dummy in the original, but with this patch,
>    it would not), which is time consuming, that is.
>
>    I trust you made sure that branch.d.dummy is never used after
>    this test is done---it would have been good to explain it either
>    in the proposed log message or after three-dash that you did
>    check and how to save reviewer bandwidth.

I will add a comment, and will (first) more diligently check for
dependencies on things now-removed.

My strategy was, frankly, a little more haphazard: eyeball the intent,
look for references in the following couple tests, and otherwise
assume that if the tests still pass, it means they didn't unexpectedly
depend on this.

Fwiw, the not-trivial-but-still-straightforward approach I'm using is
to search case-sensitively for the word "d" in this example. a, b, c
and d are all bad because they are common english words or flags used
throughout this test, but other letters and combinations are easier to
check in this reasonably-simple way.

>
>  - Are you deliberatly leaving branch.e.dummy uncleaned, or is it a
>    mere oversight?
>

Somewhere in-between. My intent with these changes was to use the
right helpers/patterns, but I did not aspire to making sure nothing
leaks between tests at all.

Generally speaking, none of the tests I've seen (in this file or
others) clean up / delete the *branches* they create - presumably
because there's no significant need - the existence of branches rarely
or never has side-effects unless explicitly referenced. Config, on the
other hand, is a good thing to clean up by default, because it is much
more likely to interfere with later tests.

Something like configuring "branch.x.dummy" (or the more meaningful
"branch.x.merge") straddles those 2 worlds - I would use test_config
to be consistent if setting one manually, but it's still
branch-specific stuff so I wouldn't be diligent about removing it if
it was created as a side-effect of another command like "git branch
-c" - just like I'm not removing the new branch itself.

That said, now that you've called my attention to it, I'll look for
leaky branch configs :)

I will also add a note clarifying "intend to use the right
patterns/helpers, but not necessarily to eliminate state leaks between
tests" in the commit message.

> >  test_expect_success 'git branch --copy is a synonym for -c' '
> >       git branch --create-reflog copy &&
> >       git reflog exists refs/heads/copy &&
> > -     git config branch.copy.dummy Hello &&
> > +     test_config branch.copy.dummy Hello &&
> >       git branch --copy copy copy-to &&
> >       git reflog exists refs/heads/copy &&
> >       git reflog exists refs/heads/copy-to &&
> > -     echo Hello >expect &&
> > -     git config branch.copy.dummy >actual &&
> > -     test_cmp expect actual &&
> > -     echo Hello >expect &&
> > -     git config branch.copy-to.dummy >actual &&
> > -     test_cmp expect actual
> > +     test_cmp_config Hello branch.copy.dummy &&
> > +     test_cmp_config Hello branch.copy-to.dummy
> >  '
>
> The same comment for branch.copy.dummy and branch.copy-to.dummy
> applies.
>
> I'll stop here for now.  Thanks for starting this clean-up.

Thank you!

      reply	other threads:[~2022-05-12  5:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  6:51 [PATCH] t3200: fix antipatterns in existing branch tests Tao Klerks via GitGitGadget
2022-03-21 13:47 ` Ævar Arnfjörð Bjarmason
2022-03-22 19:22   ` Tao Klerks
2022-03-23  0:23 ` [PATCH v2] " Tao Klerks via GitGitGadget
2022-04-30 18:42   ` [PATCH v3] " Tao Klerks via GitGitGadget
2022-05-04 17:27     ` Junio C Hamano
2022-05-12  5:12       ` Tao Klerks [this message]

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='CAPMMpogxDfmoc_9CnL6x2Hf79BgWDrq=3KfMrbc+xwyo1k=yJQ@mail.gmail.com' \
    --to=tao@klerks.biz \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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.
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).