From: Ævar Arnfjörð Bjarmason <email@example.com> To: Stefan Beller <firstname.lastname@example.org> Cc: Lars Schneider <email@example.com>, Junio C Hamano <firstname.lastname@example.org>, Git Mailing List <email@example.com> Subject: Re: [PATCH] test-lib: add ability to cap the runtime of tests Date: Mon, 5 Jun 2017 22:37:18 +0200 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 <firstname.lastname@example.org> 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.
prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-03 22:13 Æ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 publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox