All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Slavica Djukic <slawica92@hotmail.com>
Subject: Re: [PATCH] tests: add a special setup where prerequisites fail
Date: Tue, 14 May 2019 15:39:06 +0200	[thread overview]
Message-ID: <87ef51w3yd.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1905141434040.44@tvgsbejvaqbjf.bet>


On Tue, May 14 2019, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Tue, 14 May 2019, Ævar Arnfjörð Bjarmason wrote:
>
>> On Tue, May 14 2019, Johannes Schindelin wrote:
>>
>> > What would you think about a mode where random test cases are skipped?
>> > It would have to make sure to provide a way to recreate the problem,
>> > e.g. giving a string that defines exactly which test cases were
>> > skipped.
>> >
>> > I am *sure* that tons of test scripts would fail with that, and we
>> > would probably have to special-case the `setup` "test cases", and we
>> > would have to clean up quite a few scripts to *not* execute random
>> > stuff outside of `test_expect_*`...
>>
>> I think it would be neat, but unrelated to and overkill for spotting the
>> practical problem we have now, which is that we *know* we skip some of
>> this now on some platforms/setups due to prereqs.
>
> I understand, but I am still worried that this is a lot of work for an
> incomplete fix.
>
> For example, the t7600-merge.sh test script that set off this conversation
> has two prereqs that are unmet on Windows: GPG and EXECKEEPSPID. On Azure
> Pipelines' macOS agents, it is only GPG that is unmet. So switching off
> all prereqs would not help macOS with e.g. a bug where the GPG test cases
> are skipped but the EXECKEEPSPID test case is not.

It won't catch such cases, but will catch cases where a later new test
assumes that whatever the state of the test repo it gets is what's
always going to be there. In practice I think that'll catch most such
issues.

The other GIT_TEST_* modes assume similar non-combinatorial explosion
failure scenarios.

I haven't gone back through the test suite's commit history to try to
dig for other cases, so perhaps this mode is premature etc.

  reply	other threads:[~2019-05-14 13:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 17:23 What's cooking in git.git (May 2019, #01; Thu, 9) Junio C Hamano
2019-05-08 17:48 ` Denton Liu
2019-05-08 18:02 ` Elijah Newren
2019-05-09 13:24 ` Phillip Wood
2019-05-10 13:49   ` Johannes Schindelin
2019-05-13 13:29     ` Phillip Wood
2019-05-09 13:44 ` Duy Nguyen
2019-05-09 20:45 ` en/fast-export-encoding, was " Johannes Schindelin
2019-05-10  0:14   ` Elijah Newren
2019-05-10  6:21     ` Johannes Sixt
2019-05-10 13:54       ` Johannes Schindelin
2019-05-09 20:54 ` nd/merge-quit, " Johannes Schindelin
2019-05-10  9:42   ` Duy Nguyen
2019-05-13 14:02     ` Johannes Schindelin
2019-05-13 14:06       ` Johannes Schindelin
2019-05-13 14:20         ` Eric Sunshine
2019-05-13 14:53           ` Johannes Schindelin
2019-05-13 18:32       ` [PATCH] tests: add a special setup where prerequisites fail Ævar Arnfjörð Bjarmason
2019-05-14  8:53         ` Johannes Schindelin
2019-05-14  9:41           ` Ævar Arnfjörð Bjarmason
2019-05-14 12:37             ` Johannes Schindelin
2019-05-14 13:39               ` Ævar Arnfjörð Bjarmason [this message]
2019-05-14 14:04                 ` Johannes Schindelin
2019-06-20 20:42         ` [PATCH] tests: mark two failing tests under FAIL_PREREQS Ævar Arnfjörð Bjarmason
2019-06-21 18:04           ` Johannes Schindelin
2019-06-21 18:26             ` Ævar Arnfjörð Bjarmason
2019-06-21 20:08               ` Junio C Hamano

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=87ef51w3yd.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=slawica92@hotmail.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.