git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Lars Schneider <larsxschneider@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] test-lib: add ability to cap the runtime of tests
Date: Mon, 5 Jun 2017 22:37:18 +0200	[thread overview]
Message-ID: <CACBZZX6CQsJwJDXA_RtQ5YRzcGJnGrO2NoCu7Ys5FWO4dzdhVQ@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kZn+bjtqBYTWuYqfsKdA=eWreNHQPCLVDGiS_8977VcTA@mail.gmail.com>

On Mon, Jun 5, 2017 at 9:03 PM, Stefan Beller <sbeller@google.com> wrote:
>> That's never going to be a problem on a less beefy machine with
>> --state=slow,save, since the 30s test is going to be long over by the
>> time the rest of the tests run.
>>
>> Cutting down on these long tail tests allows me to e.g. replace this:
>>
>>     git rebase -i --exec '(make -j56 all && cd t && prove -j56 <some
>> limited glob>)'
>>
>> With a glob that runs the entire test suite, with the rebase only
>> taking marginally longer in most cases while getting much better test
>> coverage than I'd otherwise bother with.
>
> I wonder if this functionality is rather best put into prove?

It would be nice to have a general facility to abort & kill tests
based on some criteria as they're run by Test::Harness, but making
that work reliably with all the edge cases prove needs to deal with
(tens/hundreds of thousands of test suites) is a much bigger project
than this.

> Also prove doesn't know which tests are "interesting",
> e.g. if you were working on interactive rebase, then you really
> want the longest test to be run in full?

If I were hacking rebase or another feature which has such a long
running test then the long running test without the timeout would be
part of my "regular" testing.

The point of this feature is that most tests aren't like that, then
you can use this and do the full test suite every time.

> And this "judge by time, not by interest" doesn't bode well with
> me.

They're not mutually exclusive.

> I have a non-beefy machine such that this particular problem
> doesn't apply to me, but instead the whole test suite takes just
> long to run.
>
> For that I reduce testing intelligently, i.e. I know where I am
> working on, so I run only some given tests (in case of
> submodules I'd go with "prove t74*") which would also fix
> your issue IIUC?

No, because even when you're working on e.g. "grep" something you're
doing occasionally breaks in some completely unrelated test because it
happens to cover an aspect of grep which is not part of the main
tests.

I ran into this recently while hacking the wildmatch() implementation.
There's dozens of tests all over the test suite that'll break in
subtle ways if wildmatch() breaks, often in cases where the main
wildmatch test is still passing.

Running the whole thing, even in a limited timeout fashion, has a much
higher chance of catching whatever I've screwed up earlier, before I
do an occasional full test suite run. Running the tests in 10 or 15s
is a much shorter time to wait for during a edit/compile/test cycle.

      reply	other threads:[~2017-06-05 20:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 22:13 [PATCH] test-lib: add ability to cap the runtime of tests Ævar Arnfjörð Bjarmason
2017-06-04  0:31 ` Junio C Hamano
2017-06-04  7:29   ` Ævar Arnfjörð Bjarmason
2017-06-05  1:55     ` Junio C Hamano
2017-06-05  5:48       ` Christian Couder
2017-06-05 18:56         ` Stefan Beller
2017-06-07 10:24       ` Jeff King
2017-06-08  0:59         ` Ramsay Jones
2017-06-05 13:17     ` Lars Schneider
2017-06-05 18:15       ` Ævar Arnfjörð Bjarmason
2017-06-05 19:03         ` Stefan Beller
2017-06-05 20:37           ` Ævar Arnfjörð Bjarmason [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CACBZZX6CQsJwJDXA_RtQ5YRzcGJnGrO2NoCu7Ys5FWO4dzdhVQ@mail.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.com \
    --cc=sbeller@google.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).