db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1162) Add mechanism to assert/compare SQLStates
Date Wed, 29 Mar 2006 15:00:32 GMT
Daniel John Debrunner (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1162?page=comments#action_12372258 ]

> 
> Daniel John Debrunner commented on DERBY-1162:
> ----------------------------------------------
> 
> SQLStates are always five characters so I'm not sure why the method needs to truncate
the expected value.
> 
> From the comments in the description it seems as though you are expecting tests should
use constants from the engine's SQLState.
> That is not good practice, it is not part of the public api and it can lead to hidden
bugs.
> 
> If a test is checking for SQLState.SOME_ERROR in a test, then if a error in coding changes
that, say from a SQL Standard 23001 error
> to 2E001 then the test will continue to pass, even though a bug was introduced.

I've seen this approach been used before in tests.
Do you suggest we instead "hardcode" the SQLStates, i.e. instead of 
SQLState.SOME_ERROR we use "23001"?

I see your point, but aren't the odds for an incorrect change in 
SQLState a lot higher than a piece of code throwing the incorrect 
SQLState? These changes are most likely reviewed before they are 
committed. Also, the use of constants are usually more verbose and gives 
more information than just using the 5 character SQLState. One can of 
course create own local constants.

We will still catch the errors where SQLState.THIS_ERROR is thrown 
instead of SQLState.SOME_ERROR, which are the errors I have in mind when 
writing tests. I have never thought of testing if the values in 
SQLState.java are correct. I don't even have the required knowledge to 
know what SQLState is the correct one to be used, I usually just make it 
occur and if it has a reasonable message, I check for it in my test.



Should we revert the change to BaseJDBCTestCase and start using 
hardcoded values or create test local constants for SQLStates?




--
Kristian

> 
>> Add mechanism to assert/compare SQLStates
>> -----------------------------------------
>>
>>          Key: DERBY-1162
>>          URL: http://issues.apache.org/jira/browse/DERBY-1162
>>      Project: Derby
>>         Type: Sub-task
>>   Components: Test
>>     Versions: 10.2.0.0
>>  Environment: JUnit test environment
>>     Reporter: Kristian Waagan
>>     Assignee: Kristian Waagan
>>     Priority: Minor
>>      Fix For: 10.2.0.0
>>  Attachments: DERBY-1162-1a.diff
>>
>> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal
is to be able to reference states from SQLState without having to care if the length of the
identifier is 5,7 or more characters long.
>> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but
it is too unwieldy and long. I suggest adding  'assertSQLState(String, String, SQLException)'
method to BaseJDBCTestCase.
> 


Mime
View raw message