Change the git grep test that utilizes the REG_STARTEND flag so that
it doesn't TODO pass on platforms where REG_STARTEND is supported.
Git's own harness doesn't care, but a TAP harness will report all TODO
tests that pass. Having t7008-grep-binary.sh be the only test (aside
from the test-lib.sh test) that passes a TODO test is distracting.
Before prove(1)'s test summary looked like this:
All tests successful.
Test Summary Report
-------------------
./t0000-basic.sh (Wstat: 0 Tests: 46 Failed: 0)
TODO passed: 5
./t7008-grep-binary.sh (Wstat: 0 Tests: 18 Failed: 0)
TODO passed: 11
Files=476, Tests=6071, [...]
Result: PASS
And now it'll give:
All tests successful.
Test Summary Report
-------------------
./t0000-basic.sh (Wstat: 0 Tests: 46 Failed: 0)
TODO passed: 5
Files=476, Tests=6071,
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
t/t7008-grep-binary.sh | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
@@ -59,11 +59,16 @@ test_expect_success 'git grep -Fi iLE a' 'gitgrep-FiiLEa'-# This test actually passes on platforms where regexec() supports the-# flag REG_STARTEND.-test_expect_failure'git grep ile a''-gitgrepilea-'+ifgitgrepilea+then+# This only passes on platforms where regexec() supports the+# REG_STARTEND flag.+test_expect_success'git grep ile a''git grep ile a'+else+# On platforms where REG_STARTEND isn't supported we mark the+# failure as a TODO.+test_expect_failure'git grep ile a''git grep ile a'+fi test_expect_failure'git grep .fi a''gitgrep.fia
From: Junio C Hamano <hidden> Date: 2016-06-15 22:49:06
Ævar Arnfjörð Bjarmason [off-list ref] writes:
+if git grep ile a
+then
+ test_expect_success 'git grep ile a' 'git grep ile a'
+else
+ test_expect_failure 'git grep ile a' 'git grep ile a'
+fi
So if command "X" is known to succeed, we run it inside expect_success
and if not we run it inside expect_failure?
What kind of idiocy is that, I have to wonder...
On Thu, Jul 8, 2010 at 19:40, Junio C Hamano [off-list ref] wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
+if git grep ile a
+then
+ test_expect_success 'git grep ile a' 'git grep ile a'
+else
+ test_expect_failure 'git grep ile a' 'git grep ile a'
+fi
So if command "X" is known to succeed, we run it inside expect_success
and if not we run it inside expect_failure?
What kind of idiocy is that, I have to wonder...
Well, the point is to normalize the test suite so that we never have
passing TODO tests if everything's OK.
From: René Scharfe <hidden> Date: 2016-06-15 22:49:06
Am 08.07.2010 22:09, schrieb Ævar Arnfjörð Bjarmason:
On Thu, Jul 8, 2010 at 19:40, Junio C Hamano [off-list ref] wrote:
quoted
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
+if git grep ile a
+then
+ test_expect_success 'git grep ile a' 'git grep ile a'
+else
+ test_expect_failure 'git grep ile a' 'git grep ile a'
+fi
So if command "X" is known to succeed, we run it inside expect_success
and if not we run it inside expect_failure?
What kind of idiocy is that, I have to wonder...
Well, the point is to normalize the test suite so that we never have
passing TODO tests if everything's OK.
In this particular case the tested functionality is not provided accross
all platforms supported by git. It would be better to fix the actual
issue, namely that the fallback regex lib we provide doesn't support
REG_STARTEND.
René
On Thu, Jul 8, 2010 at 21:58, René Scharfe [off-list ref] wrote:
In this particular case the tested functionality is not provided accross
all platforms supported by git. It would be better to fix the actual
issue, namely that the fallback regex lib we provide doesn't support
REG_STARTEND.
We're currently providing the GNU regex library, it seems Mac OS X and
FreeBSD ship with a regex library that has REG_STARTEND (according to
`git log --reverse compat/regex` the current library was added because
of incompatibilities on OSX, but those were since fixed in
310e0216c8).
If the FreeBSD and Mac OS X implementations are good enough we could
just swap the GNU one for the FreeBSD one
(http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/regex/). Is there
any reason not to do this, or would a different regex library be a
better fit?