>>>>> "DVC" == David Van Couvering <[EMAIL PROTECTED]> writes:
DVC> Thanks for this very careful review, Oystein. Responses below.
DVC> �ystein Gr�vlen wrote:
>> - Why do you want to write something in
>> TestUtil.checkUniqueToString? It just creates a lot of hazzle
>> to have to sed this from the tests. If I were to write a test
>> that needed to check that strings were not equal, I think I
>> would make my on method instead of reusing this method in order
>> not to have to worry about "sedding". (I also think
>> ...NotEqual.. is a more descriptive name than ...Unique... for
>> this method.)
DVC> I wanted to test both that they were not equal, and I wanted to make
DVC> sure the output format was correct. If the sed doesn't work, that
DVC> means the format is incorrect, and then I can look at the output to
DVC> see what went wrong. Just checking to make sure they weren't equal
DVC> without ensuring the format was right made me nervous. I suppose I
DVC> was lazy in that I could have written a routine that validated the
DVC> format rather than using the master output file mechanism to do the
DVC> heavy lifting for me.
But except from the explicit output from TestUtil.checkUniqueToString
your sed matches everything to the end of line. I do not see how you
can verify any format that way.
DVC> BTW, I created TestUtil.checkUniqueToString, I'm not reusing an
DVC> existing method.
I think you must misunderstood what I meant here. I guess the reason
for having checkUniqueString as part of TestUtil is that is is a
general utility function that could be used by other tests. I think
its output make it less usable for other tests. I also think the name
is not very describing since the only thing the function does is to
test whether the output of toString for two input objects are equal or
not.
>> - The tests now test that the Ids of two connections are not
>> equal. However, for all possible bugs giving a non-unique id, I
>> would think that only a very few would give equal ids to two
>> connections opened in sequence. Would it not be better to check
>> against all currently open connections?
DVC> I was actually checking for the most common bug, where you're reusing
DVC> the same id over and over again.
DVC> I think if you want to be picky, what you really want is to make sure
DVC> that any given string doesn't match any other string that has occurred
DVC> thus far. I should keep a hashtable of all connection strings
DVC> obtained and each time I test I make sure it's not in the existing
DVC> hash table and then add it. I can create this test.
I think that is the ideal solution. However, I am not sure how much
effort one should put into testing this. I guess it is really the
responsibility of the implementor of UUID to test this, not all the
classes that uses UUID.
--
�ystein
