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 Wed, 08 Feb 2006 18:32:12 GMT
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