db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Date Wed, 08 Feb 2006 21:25:10 GMT
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