Re: [PATCH] t6024-recursive-merge.sh: hide spurious output when not running verbosely
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Mar 1, 2008, 04:27 UTC
- Message-ID
- <20080301042739.GX8410@spearce.org>
- In-Reply-To
- <20080301041005.GA8969@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
Show 24 quoted lines
> On Fri, Feb 29, 2008 at 03:50:03PM -0800, Junio C Hamano wrote: > > > Actually, I think this might be a bit more sensible approach. > > > > -- >8 -- > > tests: allow optional clean-up phrase to expect_success/failure > > > > When one test modifies the state of the test repository that the later > > tests may depend on, you may want to add a clean-up action that is run > > regardless of the outcome of the main part of the test. > > I think your heart is in the right place with this patch, but I doubt > that it is going to be all that productive in practice. Most tests > consist of a long list of commands, and cleaning up properly after every > possible failure case is going to be a lot of work. And worse, since the > tests generally _don't_ fail, you have no way to test that your cleanup > is reasonable. > > So I think we will end up in the case where a few failed tests will > properly clean themselves up and let further tests proceed, but most > failures will leave a big question. In other words, what problem have we > solved? If tests N and N+k both fail, would you, even with this patch, > suspect N+k of actually failing, or would you first go and debug test N? > Is that any different than what you do now?
I agree with Jeff. It is unnecessary complexity that won't be tested well enough to be worthwhile.
This is why when tests start to fail I just rerun the specific case with "-i -v" and let the test stop on the first failure, *fix that one case* and run again to see if anything else is going to barf.
-- Shawn.