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.
