> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
> Sent: maandag 21 februari 2011 18:40
> To: Noorul Islam K M; Subversion
> Cc: Stefan Sperling
> Subject: Re: [PATCH] cat_tests.py: Modify expected error string to use
only
> error codes.
>
> On Mon, Feb 21, 2011 at 4:19 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Mon, Feb 21, 2011 at 12:46:25PM +0530, Noorul Islam K M wrote:
> >>
> >> Modify expected error string to use only error codes and also restrict
> >> one of the lines to less than 80 characters.
> >>
> >> Log
> >> [[[
> >>
> >> * subversion/tests/cmdline/cat_tests.py
> >> (cat_local_directory, cat_remote_directory, cat_nonexistent_file,
> >> cat_skip_uncattable, cat_unversioned_file,
> >> cat_url_special_characters, cat_non_existing_remote_file):
> >> Modify expected error string to use only error codes.
> >>
> >> (cat_skip_uncattable): Restrict line length to < 80
> >>
> >> Patch by: Noorul Islam K M <noorul{_AT_}collab.net>
> >> ]]]
> >>
> >
> > Sorry that I'm being rejecting again :)
> >
> > But I think there is value in seeing the error message in the test code.
> > It makes it much easier for those reading the test code to follow
> > what kind of error the test is expecting. If all people can go by
> > is the error code, then they'll have to keep looking up error codes
> > to understand what the test is trying to do.
> > I think that's worse than adjusting tests when the message changes
> > every once in a while.
>
> And I'll say what I've been saying for a while: the test suite
> supports providing the error code (as an integer) for the expected
> error. That means that you can say 'svntest.err.CLIENT_INVALID_ARGS'
> (or whatever the error code is) instead of providing a regex with the
> actual code as a string. I've yet to hear why this isn't an
> acceptable solution to this problem.
>
> If you want to test for a specific error (which I think is of value),
> but don't care what the actual message is (since it may change, or be
> in a different locale, or whatever), just provide the error code,
> conveniently mapped in svntest.err.
I can think of a few reasons against this new method for the short term:
* In a lot of cases you want to check if a specific path is part of the
error (remains valid)
* You want to compare the test result with 1.6 (or earlier)
Until a few weeks ago we didn't print the error code so third party code
invoking svn is more likely to check the error message then this new error
output for the near future.
Over time we should start checking error codes, but until we release the
first version with the new output no user of svn will have any problem when
an error code changes.
(But users of our bindings might, but the recent changes changed the error
codes svn specific)
Bert
Received on 2011-02-21 19:40:21 CET