On Mon, Feb 21, 2011 at 4:19 AM, Stefan Sperling <[email protected]> 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. -Hyrum
