db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Date Thu, 13 Oct 2005 04:12:06 GMT
    [ 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...

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


- 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:
>     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:
For more information on JIRA, see:

View raw message