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

Re: [PATCH/RFC] Add test_repo_expect_success for running tests in a new repository

From
Jeff King <peff@peff.net>
Date
Sep 21, 2015, 18:23 UTC
Message-ID
<20150921182300.GA32514@sigill.intra.peff.net>
In-Reply-To
<1442712302-7912-1-git-send-email-pclouds@gmail.com>
On Sun, Sep 20, 2015 at 08:25:02AM +0700, Nguyễn Thái Ngọc Duy wrote:
Show 16 quoted lines
> This could be convenient when tests are independent from the rest in the
> same file. Normally we would do this
> 
> test_expect_success '...' '
> 	git init foo &&
> 	(
> 		cd foo &&
> 		<script>
> 	)
> '
> 
> Now we can write a shorter version
> 
> test_repo_expect_success '...' '
> 	<script>
> '

I dunno. Like Junio, I would prefer to see some proposed conversions to be able to evaluate it.

But I do not find the first one all that bad. Sure, it is more lines, but it is also a lot more _flexible_. You can "init --bare". You can create a repo, do some setup in it, then do some more stuff outside, and then do some more setup inside it.

I also find it weird to happen at the "test_expect_success" layer, rather than inside, as it seems somewhat orthogonal. E.g., how do I expect failure?

It seems like it would be more flexible as a helper inside the test snippet. But then I cannot think of a way to write it that is much shorter than "(cd x && ...)".

For single git commands, I do find myself increasingly writing the first one as:

  test_expect_success '...' '
	git init foo &&
	git -C foo something
  '

which is pretty short and clear, I think. It also keeps ancillary files at the top-level. So if you do:

  git clone . foo &&
  git rev-parse refs/heads/master >expect &&
  git -C foo rev-parse refs/remotes/origin/master >actual &&
  test_cmp expect actual

all of the "expect" and "actual" appear at the same top-level, and you do not have to worry about mentioning "../expect", etc.

My biggest problem with that technique is that you cannot run test_* functions this way, so:

  git -C foo test_commit bar
does not work, and you have to write:
  (cd foo && test_commit bar)
though IMHO that is not so bad.

Like I said, though, I'd reserve judgement until I saw some proposed conversions.

If we have a whole series of tests that are all supposed to be inside "foo", I wonder if it would be that distasteful to simply "cd foo", run the tests, and then cd back. Of course we'd want to notice if the "cd" failed for whatever reason. Perhaps something like:

  test_pushdir foo
  test_expect_success ...
  test_popdir

where "pushdir" would set an "error" flag if it fails, and any tests inside it would auto-fail without running (which is much safer than trying to run them in the wrong directory!).

This could also be extended to any other type of state mutation besides "cd" if we wanted, though I do not have anything in mind (I guess we could set env variables, but we usually just do that inside a test_expect and assume it worked in subsequent tests).

-Peff
Previous: Junio C Hamano
Message 3 of 3 in “Add test_repo_expect_success for running tests in a new repository”
  1. Add test_repo_expect_success for running tests in a new repositoryNguyễn Thái Ngọc Duy, Sep 20, 2015
  2. Junio C HamanoSep 21, 2015
  3. Jeff KingSep 21, 2015

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.