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.
-Hyrum
Received on 2011-02-21 18:40:09 CET