[ 
http://issues.apache.org/jira/browse/DERBY-516?page=comments#action_12331953 ] 

David Van Couvering commented on DERBY-516:
-------------------------------------------

Hi, Rick.  I've been looking through your patch, a lot of good work here!  Here 
are my comments/thoughts.

First of all, has anybody besides you run a full compatibility test?  I'll do 
it if I need to, but if somebody's already done it then I don't have to...

testScript.xml
- The standard I have seen in this project is properties in ant are not 
capitalized.  Any particular reason you diverged from this?
- The "embeddedTrunk" target: I don't understand what it means to run a JDBC 
compatibility test for an embedded engine (which you call an "embedded server" 
which is confusing).  The client and the engine are both in derby.jar -- how 
can they be incompatible?  
- I also noticed that the "jdbcTrunk" target is defined but never used.   

JDBCDriverTest:

- I very much like your structure and form in this test.  You make solid use of 
subroutines that are coherent and simple, and it makes the code very readable.  
That said, you're a little sparse on comments and have a tendency to use obtuse 
class names like "TD" and "T_CN" and it would be nice if you provided a little 
more running commentary for the new reader.  Comments on your member variables 
would be great too.

- Way cool comment on COERCIONS, it took me a few mos to realize I had to read 
top-to-bottom instead of left-to-right (what on earth does
  "BBCBCDDDRILLNRSTTVV mean?!")  It also helps to read this in a tool that 
doesn't do auto-word-wrap.  You *might* want to explain this for the poor 
person first reading this...  Also explain what this table is for (e.g. yes it 
can be coerced, not it can't).

- Why do you use "Y" and "_" instead of "T" and "F"  or "Y" or "N" for your 
defines of true and false?.  It seems a bit obtuse...

- Is there a reason you check for a boolean return value of your "minion" 
subroutines rather than have each subroutine throw an exception if it fails?  
Why are you catching the exceptions in the subroutines and then printing out a 
message?  This way you get no stack trace and the tester has to search for the 
string in the code.  I would much prefer you just throw the exceptions up to 
the top level and let JUnit report a failure with the message text to help you 
figure out what's going on.

- I must be missing something, you are only defining valid types for 10.0.  Is 
this because you haven't added the boolean type yet?  What will change when you 
add it?  Given the current situation, is there any possibility of getting an 
incompatibility in your tests, given that all versions support the same types?

- As usual, I like your choice of words, like "firstTastyColumn" and 
"constructorMinion"





> Need to incorporate client backward/forward  compatibility testing into 
> testing procedures.
> -------------------------------------------------------------------------------------------
>
>          Key: DERBY-516
>          URL: http://issues.apache.org/jira/browse/DERBY-516
>      Project: Derby
>         Type: Test
>   Components: Test
>     Versions: 10.1.1.0
>     Reporter: Kathey Marsden
>     Assignee: Rick Hillegas
>  Attachments: bug516.diff
>
> Need to incorporate client backward/forward  compatibility testing into 
> testing procedures.
> New versions of the Derby network server should work with old versions of the 
> network client.  New versions of the Derby network client should work with 
> old versions of the server.  Currently that means that the 10.1 client should 
> be tested on the trunk.     The 10.2 client definitely needs to be tested 
> with the 10.1  server before release, but it would be good to start testing 
> snapshots of 10.2 client on the 10.1 branch earlier.
>    
> Note:
> Bug fixes may mean that the canons differ for different versions.
> The test harness I think is set up to allow different masters for different 
> versions.  It at least has that functionality for the DerbyNet framework
>  and it could  be expanded to cover DerbyNetClient.  The way it works is that
> the harness checks for a masters in the following order:
> functionTests/master/<framework>/ver<version>  
> functionTests/master/<framework>/
> functionTests/master/

-- 
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

Reply via email to