Hi Jameson. On Wed, 01 Feb 2012 09:24:32 -0800, Jameson Graef Rollins <jroll...@finestructure.net> wrote: > On Wed, 01 Feb 2012 14:37:53 +0400, Dmitry Kurochkin > <dmitry.kuroch...@gmail.com> wrote: > > On Wed, 01 Feb 2012 12:18:08 +0200, Tomi Ollila <tomi.oll...@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?
Filename check is a way to make sure the argument order is correct. > 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). Do you mean that people would start writing tests with filenames like: test_expect_equal_file EXPECTED1 EXPECTED2 ? That is possible, of course. But do you seriously believe that deliberately changing file names in a way that violates common sense and is inconsistent with all other code is "easier" than writing "EXPECTED OUTPUT" in the wrong order? I do not think so. And it would definately be easier to catch during review. > And you'll have to have more code to parse the argument > strings. That is one case statement, with one non-empty case, with one error call. > And you'll still get inconsistent diffs. > No, you do not. That is the point. > 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. > Ok. I plan to send a patch soon. If my arguments do not convince enough people, I will move along. Regards, Dmitry > jamie. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch