All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "David Turner" <novalis@novalis.org>,
	"Elijah Newren" <newren@gmail.com>,
	"Matheus Tavares" <matheus.bernardino@usp.br>,
	"Jeff King" <peff@peff.net>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>
Subject: Re: test-lib.sh musings: test_expect_failure considered harmful
Date: Wed, 13 Oct 2021 10:16:18 -0700	[thread overview]
Message-ID: <xmqq4k9kj15p.fsf@gitster.g> (raw)
In-Reply-To: <d643863c-7683-fe4b-e4f2-3fefc475006b@gmail.com> (Derrick Stolee's message of "Wed, 13 Oct 2021 09:05:08 -0400")

Derrick Stolee <stolee@gmail.com> writes:

>> But even with the shortcomings of expect_failure, it still is much
>> better than claiming that we expect a bogus outcome.
>> 
>> Improving the shortcomings of expect_failure would be a much better
>> use of our time than advocating an abuse of expect_sucess, I would
>> think.
>
> I agree that test_expect_failure has these drawbacks. I've recently
> been using _expect_success to document "bad" behavior so we can verify
> that behavior changes when that behavior is fixed. But it does have
> the drawback of looking like we claim the result is by design.

Yeah, I think I saw (and I think I used the same technique myself)
people expect a bad output with test_expect_success with an in-code
(not in-log) comment that explicitly says "This documents the
current behaviour, which is wrong", and that is a very acceptable
solution, I would think.

> One possible way to correct this is to create a "test_expected_failure"
> helper that could be placed on the step(s) of the &&-chain that are
> expected to fail. The helper could set some variable to true if the
> failure is hit, and false otherwise. It can also convert a failure
> into a positive result. Then, test_expect_failure could look for that
> variable's value (after verifying that the &&-chain returns success)
> to show that all expected failures completed correctly.

Yup, I would very much like the direction, and further imagine that
the above approach can be extended to ...

> This could have the side-effect of having a "fixed" test_expect_failure
> show as a failed test, not a "TODO" message.

... avoid such downside.  Perhaps call that magic "we know this step
fails currently" test_known_breakage and declare that we deprecate
the use of test_expect_failure in new tests.  Such a test might look
like this:

    test_expect_success 'commit error message should not duplicate' '
	test_when_finished "chmod -R u+rwx ." &&
	chmod u-rwx .git/objects/ &&
	orig_head=$(git rev-parse HEAD) &&
	test_must_fail git commit --allow-empty -m "read-only" 2>rawerr &&
	grep "insufficient permission" rawerr >err &&
	test_known_breakage test_line_count = 1 err &&
	new_head=$(git rev-parse HEAD) &&
	test "$orig_head" = "$new_head"
    '

which may use your trick to turn both failure and success to OK (to
let the remainder of the test to continue) but signal the
surrounding test_expect_success to say either "TODO know breakage"
or "Fixed".

Thanks.


  reply	other threads:[~2021-10-13 17:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  9:23 test-lib.sh musings: test_expect_failure considered harmful Ævar Arnfjörð Bjarmason
2021-10-12 16:45 ` Junio C Hamano
2021-10-13 10:10   ` Ævar Arnfjörð Bjarmason
2021-10-13 13:05   ` Derrick Stolee
2021-10-13 17:16     ` Junio C Hamano [this message]
2021-10-14 17:11       ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4k9kj15p.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=matheus.bernardino@usp.br \
    --cc=newren@gmail.com \
    --cc=novalis@novalis.org \
    --cc=peff@peff.net \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.