db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Date Thu, 09 Feb 2006 02:01:12 GMT
I would say you could put the new tests into the tests/jdbcapi directory 
and log a JIRA to move over the other tests, rather than try and swallow 
that into your patch, that's too much for one patch.

David

Andreas Korneliussen wrote:
> Hi all,
> Thanks for reviewing the patch.
> 
> The junitTest directory was not introduced as part of this patch. it had 
> been introduced from before, and all (3-4) junit tests are in that 
> subdirectory.
> 
> However I agree that it is not necessary to have a separate tree for 
> JUnit type tests - so what should I do ?
> a, put the new tests into the tests/jdbcapi directory
> b, put them into a new directory : tests/junitTest/jdbcapi
> 
> If I go for a, the existing junit tests should then also be moved.
> 
> Either way is fine with me.
> 
> --Andreas
> 
> David W. Van Couvering wrote:
> 
>> I am also a bit uncomfortable with a separate subdirectory for junit 
>> tests.  Is there a specific reason for this segregation?  If we have a 
>> new test type, .junit, why can't that be sufficient to distinguish 
>> between a JUnit test and an "old-style" test?  I'd like to reuse the 
>> existing subdirectories like lang and jdbcapi rather than create a 
>> mirror of subdirectories, or even a completely orthogonal set of 
>> subdirectories, under junitTests.
>>
>> David
>>
>> Daniel John Debrunner (JIRA) wrote:
>>
>>>     [ 
>>> http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574

>>> ]
>>> Daniel John Debrunner commented on DERBY-934:
>>> ---------------------------------------------
>>>
>>> Is this the plan for junit tests, to have a test directory per 
>>> function, namely the 'sur' directory here?
>>>
>>>  junitTests/sur/SURTest.junit
>>> If these tests were added under the old harness the correct location 
>>> would be
>>>
>>> tests/jdbcapi
>>>
>>> The existing junitTests sub-directories are higher level than a set 
>>> of functionality and two of the three match the exisitng harness 
>>> layout, lang and bderyNet
>>>
>>>
>>>
>>>
>>>> create a set of JUnit tests for Scrollable Updatable Resultsets
>>>> ---------------------------------------------------------------
>>>>
>>>>         Key: DERBY-934
>>>>         URL: http://issues.apache.org/jira/browse/DERBY-934
>>>>     Project: Derby
>>>>        Type: Sub-task
>>>>  Components: Test
>>>>    Reporter: Andreas Korneliussen
>>>>    Assignee: Andreas Korneliussen
>>>> Attachments: DERBY-934.diff, DERBY-934.stat
>>>>
>>>> Add a set of JUnit tests which tests the implementation for 
>>>> Scrollable Updatable ResultSets.
>>>> The following is a description of how the tests will be implemented:
>>>> Data model in test:
>>>> We use one table containing three int fields and one varchar(5000)
>>>> field. Then we run the tests on a number of variants of this model:
>>>> 1. None of the fields are indexed (no primary key, no secondary key)
>>>> 2. One of the fields is indexed as primary key
>>>> 3. One of the fields is indexed as primary key, another field is
>>>>   indexed as secondary key
>>>> 4. One field is indexed as secondary key
>>>> (primary key is unique, secondary key is not unique)
>>>> By having these variations in the data model, we cover a number of
>>>> variations where the ScrollInsensitiveResultSet implementation uses
>>>> different classes of source ResultSets, and the CurrentOfResultSet
>>>> uses different classes of target and source ResultSet.
>>>> The table can be created with the following fields:
>>>> (id int, a int, b int, c varchar(5000))
>>>> -
>>>> Queries for testing SUR:
>>>> Select conditions:
>>>> * Full table scan
>>>> SQL: SELECT * FROM T1
>>>> * Full table scan with criteria on non-indexed field
>>>> SQL: .. WHERE c like ?
>>>> SQL: .. WHERE b > ?
>>>> * Full table scan with criteria on indexed field
>>>> SQL: .. WHERE id>a
>>>> * SELECT on primary key conditionals:
>>>> - Upper and lower bond criteria:
>>>> SQL: .. WHERE ID>? and ID<?
>>>> SQL: .. WHERE ID=? -- (Single tuple)
>>>> * Nested queries:
>>>> SQL: .. WHERE ID in (1,2,3,4) SQL: .. WHERE a  in (1,2,3,4) (Other 
>>>> nested queries containing a table seems to not permit updates)
>>>> * SELECT on secondary key conditionals:
>>>> SQL: .. WHERE a>? and a<?
>>>> SQL: .. WHERE a=?
>>>> * Projections:
>>>> SQL: SELECT id,a,b,c
>>>> SQL: SELECT id,c,b,a
>>>> SQL: SELECT id,c
>>>> SQL: SELECT id,a
>>>> SQL: SELECT a,b,c
>>>> SQL: SELECT a,b
>>>> SQL: SELECT a,c
>>>> The test should generate queries with all combinations of the
>>>> projection and select conditions, and then run a number of tests:
>>>> - test navigiation
>>>> - test updates + navigation
>>>> - test deletes + navigation
>>>> - check rowUpdated() and rowDeleted() fields
>>>> Scrollability: All scroll-insensitive cursors should be checked for
>>>> scrollability. Scrolling is tested by invoking: next(), previous(),
>>>> beforeFirst(), afterLast(), absolute(), relative(),  isBeforeFirst(),
>>>> isAfterLast(), isFirst(), isLast(),
>>>> Updating a scrollable resultset: a ResultSets current row can be
>>>> updated either by using updateXXX() + updateRow(), or by using
>>>> a positioned update query.  All tests which updates row, will come in
>>>> two variants covering both these cases.
>>>> -
>>>> Deleting rows in scrollable resultset also has two variants: one using
>>>> a positioned update query, and one using deleteRow().
>>>> -
>>>> Special testcases:
>>>> Test that you get a warning when specifying a query which is not
>>>> updatable and concurrency mode CONCUR_UPDATABLE.
>>>> Case 1: Query containing order by
>>>> Case 2: Query containing a join
>>>> Exceptions:
>>>> Test that you get an exception when specifying update clause "FOR 
>>>> UPDATE"
>>>> along with a query which is not updatable.
>>>> Cases:
>>>> * Query containing order by
>>>> * Query containing a join
>>>> Test that you get an exception when attempting to update a ResultSet 
>>>> which has been downgraded to a read only ResultSet due to the query 
>>>> Cases:
>>>> * Query contained a join
>>>> * Query contained a read only update clause
>>>> * Query contained a order by
>>>> Test that you get an exception when attempting to update a ResultSet 
>>>> which has concurrency mode CONCUR_READ_ONLY
>>>>
>>>> Concurrency tests:
>>>> (ConcurrencyTest)
>>>> Cases: * Test that update locks are downgraded to shared locks after
>>>>  repositioning. (fails with derby)
>>>> * Test that we can aquire a update lock even if the row is locked with
>>>>  a shared lock.
>>>> * Test that we can aquire a shared lock even if the row is locked with
>>>>  an update lock.
>>>> * Test that we do not get a concurrency problem when opening two
>>>>  cursors as readonly.
>>>> * Test what happens if you update a deleted and purged record
>>>> * Test what happens if you update a deleted and purged record using
>>>>  positioned update
>>>> * Test what happens if you update a tuple which is deleted and then
>>>>  reinserted.
>>>> * Test what happens if you update a tuple which is deleted and then
>>>>  reinserted with the exact same values
>>>> * Test what happens if you update a tuple which has been modified by
>>>>  another transaction.
>>>> * Test that you cannot compress the table while the ResultSet is open,
>>>>  and the transaction is open (for validity of RowLocation)
>>>> * Test that you cannot purge a row if it is locked
>>>> * Test that Derby set updatelock on current row when using
>>>>  read-uncommitted
>>>
>>>
>>>
>>>
> 

Mime
View raw message