Skip to contentSkip to conversation

t5000-tar-tree.sh failing

DISCUSSION Uwe Kleine-König 3 participants 6 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Hello,

when I run make test, I get:

*** t5000-tar-tree.sh ***
Initialized empty Git repository in .git/
* ok 1: populate workdir
* ok 2: add files to repository
* ok 3: git-tar-tree
* ok 4: validate file modification time
* ok 5: git-get-tar-commit-id
* ok 6: extract tar archive
* ok 7: validate filenames
* ok 8: validate file contents
* ok 9: git-tar-tree with prefix
* ok 10: extract tar archive with prefix
* ok 11: validate filenames with prefix
* ok 12: validate file contents with prefix
* ok 13: git-archive --format=zip
* FAIL 14: extract ZIP archive
(mkdir d && cd d && $UNZIP ../d.zip)
* FAIL 15: validate filenames
(cd d/a && find .) | sort >d.lst &&
diff a.lst d.lst
* FAIL 16: validate file contents
diff -r a d/a
* ok 17: git-archive --format=zip with prefix
* FAIL 18: extract ZIP archive with prefix (mkdir e && cd e && $UNZIP ../e.zip)
* FAIL 19: validate filenames with prefix (cd e/prefix/a && find .) | sort >e.lst && diff a.lst e.lst
* FAIL 20: validate file contents with prefix diff -r a e/prefix/a
* failed 6 among 20 test(s)

I think the problem is:

	zeisberg@cepheus:~/gsrc/git$ unzip
	bash: unzip: command not found

Probably the subversion tests suffer the same (for svn instead of unzip).

Do we want the tests to depend on all that or would it be sensible to output a warning that a program is missing? Or maybe introduce test "13.5: check is unzip is available". Then it would be more obvious for the tester what went wrong?

Best regards
Uwe

Signature · 4 lines
Uwe Kleine-König

primes where sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]; \
primes = map head (iterate sieve [2..])
#1 lore raw

Hi,

Quoted 9 lines · Uwe Kleine-König

[...]

	* FAIL 14: extract ZIP archive
		(mkdir d && cd d && $UNZIP ../d.zip)

[...]

I think the problem is:

	zeisberg@cepheus:~/gsrc/git$ unzip
	bash: unzip: command not found

Yep. That's the problem.

Quoted 5 lines

Probably the subversion tests suffer the same (for svn instead of unzip).

Do we want the tests to depend on all that or would it be sensible to output a warning that a program is missing?

Why not enclose the tests in a

if unzip -h >/dev/null 2>/dev/null; then

# all these tests

fi

Hmm?

Ciao,
Dscho

#2 lore raw
Quoted 10 lines · Johannes Schindelin

Why not enclose the tests in a

if unzip -h >/dev/null 2>/dev/null; then

# all these tests

fi

Hmm?

Several other test frameworks provide a "skip" method to indicate why we've skipped something. We could do something similar...

if skip 'unzip -h' 'tests need unzip'; then

   # unzip tests
fi

skip() {
# Have not checked to see if this is anything resembling working code if eval $1 > /dev/null 2>&1; then
true
else

    echo "* skipping tests: $2" 1>&2
    false

fi
}

Mostly so that skipped tests are obvious, provide a reason, and have a standardized display format. Again, too busy in actual work to try to do this myself right now, but might hack at it this afternoon if nobody else (hopefully someone more fluent in shell than I am) does.

~~ Brian

#3 lore raw

Hello,

Quoted 14 lines · Brian Gernhardt

Several other test frameworks provide a "skip" method to indicate why we've skipped something. We could do something similar...

if skip 'unzip -h' 'tests need unzip'; then

   # unzip tests
fi

skip() {
# Have not checked to see if this is anything resembling working code if eval $1 > /dev/null 2>&1; then
true
else

    echo "* skipping tests: $2" 1>&2
    false
Quoted 7 lines

fi
}

Mostly so that skipped tests are obvious, provide a reason, and have a standardized display format. Again, too busy in actual work to try to do this myself right now, but might hack at it this afternoon if nobody else (hopefully someone more fluent in shell than I am) does.

I'm not sure if (in this case) a missing unzip should be as silent as you suggest. The danger is, that s.o. makes a change, runs make test and is then conviced that nothing broke. So I think that the test should fail, but with a more descriptive error than it is now.

The downside is, you need unzip, svn, what ever more to run the test suite.

Best regards
Uwe

Signature · 3 lines
Uwe Kleine-Koenig

http://www.google.com/search?q=gigabyte+in+bit
#4 lore raw
Quoted 7 lines · Uwe Kleine-Koenig

I'm not sure if (in this case) a missing unzip should be as silent as you suggest. The danger is, that s.o. makes a change, runs make test and is then conviced that nothing broke. So I think that the test should fail, but with a more descriptive error than it is now.

The downside is, you need unzip, svn, what ever more to run the test suite.

I was attempting to say that if we're skipping tests we should say so, and not just drop them silently like the code that Johannes posted. Really, I guess the ideal would be for there to be a test harness that would run all the tests and report skips and errors in a report at the end rather than in the middle.

~~ Brian

#5 lore raw
In reply to Uwe Kleine-Koenig

Hi,

Quoted 3 lines · Uwe Kleine-Koenig

I'm not sure if (in this case) a missing unzip should be as silent as you suggest. The danger is, that s.o. makes a change, runs make test and is then conviced that nothing broke.

Well, the tests are not distributed with the binary packages. For a reason. The maintainer of the binary packages has to check if the tests succeed. An she better know what she's doing!

So, if Joe Average compiles git, does not have unzip installed, and runs the tests, chances are that he does not want to be bothered about the zip tests failing because of the absence of unzip.

Quoted 2 lines

So I think that the test should fail, but with a more descriptive error
than it is now.

Sorry. Does not work here. I _only_ look at the messages if the test suite fails somewhere, with a loud error message at the end.

Ciao,
Dscho