unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>,
	Tomi Ollila <tomi.ollila@iki.fi>,
	notmuch@notmuchmail.org
Subject: Re: [PATCH] test: make test_expect_equal_file() arguments flexible
Date: Wed, 01 Feb 2012 09:24:32 -0800	[thread overview]
Message-ID: <87ehuetqjz.fsf@servo.finestructure.net> (raw)
In-Reply-To: <87k446n8ji.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Wed, 01 Feb 2012 14:37:53 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> On Wed, 01 Feb 2012 12:18:08 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> > 
> > There are at least these options here
> > 
> > 1) go through all ~100 places where test_expect_equal_file is used
> >    and fix the call order: quick look tells that the offending uses
> >    are in dump-restore, hooks, search-limiting and symbol-hiding.
> > 
> > 2) enforce "expected" filename has some format *and* fix all current
> >    uses of it. Add testbed_error () function which yells loudly ane exits...
> > 
> > 3) guess which is output and which is expected from args so that 
> >    machine helps tester here (for both diff output & copied files)a
> > 
> > 4) just copy compared files to some directory, those are named as
> >    basename of the original -- diff order still inconsistent.
> > 
> > 
> > I'd just go with option 1 and fix new *violations* when stumble upon one.
> > 
> 
> Option 1 does not solve the problem.  New violations would apper and
> need to be fixed again.  I am for option 2.

How is enforcing use of a particular filename better and more robust
than enforcing argument order?  You'll still have to force an arbitrary
heuristic.  And you'll still be vulnerable to people messing up the file
names (which actually seems easier to get wrong than messing up the
order).  And you'll have to have more code to parse the argument
strings.  And you'll still get inconsistent diffs.

If this is really a problem, I vote for 1.  In general, I am not in
favor of making the test suite more complicated than it needs to be.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

  reply	other threads:[~2012-02-01 17:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01  7:19 [PATCH] test: make test_expect_equal_file() arguments flexible Dmitry Kurochkin
2012-02-01  8:12 ` David Edmondson
2012-02-01  8:47 ` Jameson Graef Rollins
2012-02-01  8:55   ` Tomi Ollila
2012-02-01  9:23     ` Dmitry Kurochkin
2012-02-01  9:19   ` Dmitry Kurochkin
2012-02-01 10:18     ` Tomi Ollila
2012-02-01 10:37       ` Dmitry Kurochkin
2012-02-01 17:24         ` Jameson Graef Rollins [this message]
2012-02-01 23:42           ` Dmitry Kurochkin
2012-02-02  0:07             ` Dmitry Kurochkin
2012-02-02 14:33           ` David Edmondson
2012-02-02 15:25             ` Tomi Ollila
2012-02-02 17:40 ` Jameson Graef Rollins
2012-09-02  2:38 ` David Bremner

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: https://notmuchmail.org/

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

  git send-email \
    --in-reply-to=87ehuetqjz.fsf@servo.finestructure.net \
    --to=jrollins@finestructure.net \
    --cc=dmitry.kurochkin@gmail.com \
    --cc=notmuch@notmuchmail.org \
    --cc=tomi.ollila@iki.fi \
    /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://yhetil.org/notmuch.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).