Having a simulated "known breakage" test means that the test
suite will always tell us there is a bug to be fixed, even
though it is only simulated.
The right way to test this is in a sub-test, that can also
check that we provide the correct exit status and output.
Fortunately, we already have such a test (added much later
by 5ebf89e).
We could arguably get rid of the simulated success test
immediately above, as well, as it is also redundant with the
tests added in 5ebf89e. However, it does not have the
annoying behavior of the "known breakage" test. It may also
be easier to debug if the test suite is truly broken, since
it is not a test-within-a-test, as the later tests are.
Signed-off-by: Jeff King <p...@peff.net>
---
I am not _that_ bothered by the "known breakage", but AFAICT there is
zero benefit to keeping this redundant test. But maybe I am missing
something.
t/t0000-basic.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index e6c5b63..a2bb63c 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -41,9 +41,6 @@ test_expect_success '.git/objects should have 3
subdirectories' '
test_expect_success 'success is reported like this' '
:
'
-test_expect_failure 'pretend we have a known breakage' '
- false
-'
run_sub_test_lib_test () {
name="$1" descr="$2" # stdin is the body of the test code
--
1.8.5.1.399.g900e7cd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
