db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Date Fri, 28 Oct 2005 03:45:57 GMT
Hi David,

I think that this is all speculation about what to do in the future as 
we migrate existing tests into JUnit. No-one has proposed blocking this 
patch. Please go ahead with the commit.

Thanks,
-Rick

David W. Van Couvering wrote:

> I am *this* close to checking in Rick's patch.  Should I hold off, or 
> can we do this as a separate patch?
>
> David
>
> Rick Hillegas wrote:
>
>> What I meant by "fork" is that we could introduce a new subdirectory 
>> under org/apache/derbyTesting as Myrna suggested. Then, as tests were 
>> converted to JUnit, we could move them from their old location to a 
>> new location under the JUnitTests subdirectory. Moving would involve 
>> svn-moving the test, which means that the old version would disappear 
>> from the code tree. There would be only one version of the test in 
>> the code tree. I agree that maintaining two independent copies would 
>> be a bad idea.
>>
>> -Rick
>>
>> Daniel John Debrunner wrote:
>>
>>> John Embretsen wrote:
>>>
>>>  
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>  
>>>>
>>>>> Myrna van Lunteren (JIRA) wrote:
>>>>>
>>>>>     
>>>>
>>>>
>>>> [snip]
>>>>
>>>>  
>>>>
>>>>>> Finally I also wondered if maybe these tests ought to be not under
>>>>>> org/apache/derbyTesting/functionTests/tests/compatibility, but under
>>>>>> org/apache/derbyTesting/JUnitTests/compatibility...
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>> I don't have strong religion about these points either. Concerning 
>>>>> the
>>>>> last issue: I agree that a JUnitTests fork in the tree might help us
>>>>> track which of our existing tests we've migrated under JUnit.
>>>>>
>>>>>     
>>>>
>>>>
>>>> I agree, I think we could avoid a lot of potential confusion regarding
>>>> Derby testing in the future by having (from the start) an easy way to
>>>> see which tests are written for JUnit and which are not, especially as
>>>> more JUnit-based tests are added. Forking the derbyTesting source tree
>>>> might be a good way to do this - at least I cannot come up with any
>>>> better ideas at the moment.
>>>>   
>>>
>>>
>>>
>>> Do you mean forking, or just a separate directory structure within
>>> derbyTesting?
>>>
>>> Forking means a copy of the tree developed independently, not sure why
>>> we would want to go down that path.
>>>
>>>
>>> Dan.
>>>
>>>  
>>>
>>


Mime
View raw message