You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/09/02 19:11:23 UTC

[jira] Commented: (DERBY-1802) JUnit tests for DERBY-475 and DERBY-592, Built-in and JDBC escape functions

    [ http://issues.apache.org/jira/browse/DERBY-1802?page=comments#action_12432294 ] 
            
Daniel John Debrunner commented on DERBY-1802:
----------------------------------------------

Thanks for the comprehensive test Susan (much better than the minimal testing I submitted with the initial changes), some comments:

- The apache licence header is the first item in a source file, before the package statement and imports, see other .java files for examples:

- In Java constants like SMALLEST_NEG_DERBY_DOUBLE  should be declared final
    private static final double SMALLEST_NEG_DERBY_DOUBLE = -1.79769E+308;

- For the various constants it might be good to have comments around them indicting what they mean,
   for example it was unclear to me what  was special about LITTLE_RADIANS that  it needed a constant.

- Maybe a style issue, but I prefer not to have constants like:
    QUARTER_RADIANS, NEG_QUARTER_RADIANS, HALF_RADIANS, ZERO_RADIANS etc.
     Are they really adding value? Or would the code be clearer just saying
               double radians = 0.25;
     Constants are usually used to hide the specific value (e.g. 0.25) and provide a logical name for understanding,
      here the constant's name is defining the specific value (QUARTER_RADIANS)

- For PI instead of defining your own constant, PI_RADIANS, you can just use the one from StrictMath directly
   Similar, do the constants for 2*PI etc  really add value?

- For the methods executeNullValues and executeNullFn would it make sense to move the check that the return is
NULL into the method and not have all the callers check it? Then you could also check within the method that only
one row is returned and that the wasNull() indicator matched the state of the value.

- You use static variables which will cause problems in the future when we want to run tests in parallel as there may be multiple
threads sharing those varaibles as each runs an instance of this class. E.g.
  private static double rValue;

Unless there's some special need I'm missing theie use seems to be self-contained within each test.
The correct way to  write this is to have local scope variables, not static fields, e.g.

+		for (int i = 0; i < testValues.length; i++) {
+			double expected = java.lang.StrictMath.tan(testValues[i]);                        <<<<<<< changed line
+			double rValue = executeValues("TAN", testValues[i]);                              <<<<<<< changed line
+			debug("TAN: input value: " + testValues[i] + " expected value: "
+					+ expected + " return value: " + rValue);
+			assertEquals(expected, rValue, 0.0);
+			float fValue = executeFn("TAN", testValues[i]);                                             <<<<<<< changed line
+			assertEquals(expected, fValue, 0.0);
+		}

- For checkng the SQL State values
+			BaseJDBCTestCase
+					.assertSQLState(
+							"SQLState was NOT correct",
+							SQLStateConstants.DATA_EXCEPTION_NUMERIC_VALUE_OUT_OF_RANGE,
+							sqlE);

There's no need to have the BaseJDBCTestCase., you can just say assertSQLState. That owuld match the typical
use of static assert methods in JUnit tests.

Since all of the messages you pass into assertSQLState are generic "SQLState was NOT correct", you could use the two argument
value which has a similar generic message.

assertSQLState(SQLStateConstants.DATA_EXCEPTION_NUMERIC_VALUE_OUT_OF_RANGE, sqlE);

The three argument one can be used when there is added benefit to a different message, e.g. "ASIN Conversion return incorrect SQLState"
In this case I would recommend the two argument version.
           
- the patch contains an unrelated change to LangScripts.java






> JUnit tests for DERBY-475 and DERBY-592, Built-in and JDBC escape functions
> ---------------------------------------------------------------------------
>
>                 Key: DERBY-1802
>                 URL: http://issues.apache.org/jira/browse/DERBY-1802
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>    Affects Versions: 10.3.0.0
>            Reporter: Susan Cline
>         Assigned To: Susan Cline
>            Priority: Minor
>         Attachments: DERBY-475_DERBY-592_20060831.diff
>
>
> Attached is a patch which contains JUnit tests for DERBY-475 and DERBY-592, the built-in math functions and JDBC escape functions.
> I ran the patch, DERBY-475_DERBY-592_20060831.diff, against these four tests:
> java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.lang.MathTrigFunctionsTest
> java org.apache.derbyTesting.functionTests.harness.RunTest lang/MathTrigFunctionsTest.junit
> java org.apache.derbyTesting.functionTests.harness.RunTest lang/_Suite.junit
> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
> svn status:
> A      java\testing\org\apache\derbyTesting\functionTests\tests\lang\MathTrigFunctionsTest.java
> M      java\testing\org\apache\derbyTesting\functionTests\tests\lang\_Suite.java
> M      java\testing\org\apache\derbyTesting\functionTests\tests\lang\LangScripts.java
> (Note: I edited this file, but changed it back to the original contents.)
> I created the patch on Windows XP, tested it on Windows XP and then applied the patch on Linux and ran the above 4 tests on Linux.
> sysinfo output:
> ------------------ Java Information ------------------
> Java Version:    1.4.2_09
> Java Vendor:     Sun Microsystems Inc.
> Java home:       C:\JDK\jdk1.4.2_09\jre
> Java classpath:  C:\derby_src\development_branch\trunk\classes;C:\derby_src\deve
> lopment_branch\trunk\tools\java\junit.jar;C:\derby_src\development_branch\trunk\
> tools\java\jakarta-oro-2.0.8.jar;.
> OS name:         Windows XP
> OS architecture: x86
> OS version:      5.1
> Java user name:  slc
> Java user home:  C:\Documents and Settings\Administrator
> Java user dir:   C:\derby_src\development_branch\trunk
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> --------- Derby Information --------
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\derby_src\development_branch\trunk\classes] 10.3.0.0 alpha - (1)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale :  [English/United States [en_US]]
> Found support for locale: [de_DE]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [es]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [fr]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [it]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [ja_JP]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [ko_KR]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [pt_BR]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [zh_CN]
>          version: 10.3.0.0 alpha - (1)
> Found support for locale: [zh_TW]
>          version: 10.3.0.0 alpha - (1)
> ------------------------------------------------------
> I would appreciate it if a committer would commit this patch.
> Thanks,
> Susan

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira