kernel/git - git - PowerEL Git System

Tree: b7cbbffb85

Author	SHA1	Message	Date
Stefan Beller	b0afc02649	checkout test: enable test with complex relative path This test was added, commented out, in `fed1b5ca` (git-checkout: Test for relative path use, 2007-11-09). Later git's path handling was improved (`d089ebaa`, setup: sanitize absolute and funny paths in get_pathspec(), 2008-01-28) but we forgot to enable the now-working test. This test expects to run from a subdirectory, so add a 'cd'. While we're here, examine the content of the checked-out file instead of just checking that it exists. The other checkout tests already do the same. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>	12 years ago
Junio C Hamano	90d0ed96b7	tests: introduce test_must_fail When we expect a git command to notice and signal errors, we carelessly wrote in our tests: test_expect_success 'reject bogus request' ' do something && do something else && ! git command ' but a non-zero exit could come from the "git command" segfaulting. A new helper function "tset_must_fail" is introduced and it is meant to be used to make sure the command gracefully fails (iow, dying and exiting with non zero status is counted as a failure to "gracefully fail"). The above example should be written as: test_expect_success 'reject bogus request' ' do something && do something else && test_must_fail git command ' Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	7435982102	tests: introduce test_must_fail When we expect a git command to notice and signal errors, we carelessly wrote in our tests: test_expect_success 'reject bogus request' ' do something && do something else && ! git command ' but a non-zero exit could come from the "git command" segfaulting. A new helper function "tset_must_fail" is introduced and it is meant to be used to make sure the command gracefully fails (iow, dying and exiting with non zero status is counted as a failure to "gracefully fail"). The above example should be written as: test_expect_success 'reject bogus request' ' do something && do something else && test_must_fail git command ' Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
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>	17 years ago
David Symonds	fed1b5cac0	git-checkout: Test for relative path use. Signed-off-by: David Symonds <dsymonds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago