git-commit-vandalism/t/t0040-parse-options.sh
Junio C Hamano 41ac414ea2 Sane use of test_expect_failure
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision.  Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:

    test_expect_{success,failure} 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        what is to be tested
    '

And expecting a failure exit from the whole sequence misses the
point of writing tests.  Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test.  The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.

This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:

    test_expect_success 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        ! this command should fail
    '

test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass.  So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:

    test_expect_failure 'git-foo should create bar' '
        rm -f bar &&
        git foo &&
        test -f bar
    '

This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 20:49:34 -08:00

118 lines
2.4 KiB
Bash
Executable File

#!/bin/sh
#
# Copyright (c) 2007 Johannes Schindelin
#
test_description='our own option parser'
. ./test-lib.sh
cat > expect.err << EOF
usage: test-parse-options <options>
-b, --boolean get a boolean
-i, --integer <n> get a integer
-j <n> get a integer, too
string options
-s, --string <string>
get a string
--string2 <str> get another string
--st <st> get another string (pervert ordering)
-o <str> get another string
EOF
test_expect_success 'test help' '
! test-parse-options -h > output 2> output.err &&
test ! -s output &&
git diff expect.err output.err
'
cat > expect << EOF
boolean: 2
integer: 1729
string: 123
EOF
test_expect_success 'short options' '
test-parse-options -s123 -b -i 1729 -b > output 2> output.err &&
git diff expect output &&
test ! -s output.err
'
cat > expect << EOF
boolean: 2
integer: 1729
string: 321
EOF
test_expect_success 'long options' '
test-parse-options --boolean --integer 1729 --boolean --string2=321 \
> output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
cat > expect << EOF
boolean: 1
integer: 13
string: 123
arg 00: a1
arg 01: b1
arg 02: --boolean
EOF
test_expect_success 'intermingled arguments' '
test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
> output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
cat > expect << EOF
boolean: 0
integer: 2
string: (not set)
EOF
test_expect_success 'unambiguously abbreviated option' '
test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
test_expect_success 'unambiguously abbreviated option with "="' '
test-parse-options --int=2 > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
test_expect_success 'ambiguously abbreviated option' '
test-parse-options --strin 123;
test $? = 129
'
cat > expect << EOF
boolean: 0
integer: 0
string: 123
EOF
test_expect_success 'non ambiguous option (after two options it abbreviates)' '
test-parse-options --st 123 > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
cat > expect.err << EOF
error: did you mean \`--boolean\` (with two dashes ?)
EOF
test_expect_success 'detect possible typos' '
! test-parse-options -boolean > output 2> output.err &&
test ! -s output &&
git diff expect.err output.err
'
test_done