On Fri, Dec 28, 2018 at 11:58 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > On Fri, Dec 28, 2018 at 2:51 PM Masaya Suzuki <masayasuzuki@xxxxxxxxxx> wrote: > > On Fri, Dec 28, 2018 at 11:37 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > > On Thu, Dec 27, 2018 at 8:47 PM Masaya Suzuki <masayasuzuki@xxxxxxxxxx> wrote: > > > > +test_expect_success 'failure in git-upload-pack is shown' ' > > > > + (GIT_CURL_VERBOSE=1 git clone --bare "$HTTPD_URL/error_git_upload_pack/smart/repo.git" 2>curl_log || > > > > + true) && > > > > > > Using test_might_fail() would allow you to drop the subshell and the "|| true": > > > > > > test_might_fail env GIT_CURL_VERBOSE=1 git clone ... && > > > > > > > + cat curl_log | grep "< HTTP/1.1 500 Intentional Breakage" > > > > +' > > > > The test should success. This is a test that a log is produced after a > > git command fails. The point of this test is "cat curl_log | grep ..." > > part that asserts the log. > > Unfortunately, the name "test_might_fail" is confusing. It is not > saying that the entire test might or might not fail. Rather, it is > saying that the one command might or might not fail (and that you > don't care if it does fail). The idiom: > > (some-git-command || true) && > > can be replaced with: > > test_might_fail some-git-command && > > without changing its meaning, and without affecting the > success/failure status of the test overall. > > So, this new test could be written like this: > > --- 8< --- > test_expect_success 'failure in git-upload-pack is shown' ' > test_might_fail env GIT_CURL_VERBOSE=1 git clone --bare > "$HTTPD_URL/error_git_upload_pack/smart/repo.git" 2>curl_log && > cat curl_log | grep "< HTTP/1.1 500 Intentional Breakage" > ' > --- 8< --- > > and have the same meaning. Ah. I see. It's used inside the test. Thanks.
