Re: jdbcapi/testRelative intermittent diff

[Kathey Marsden]

Hi   Shreyas,

I think we are getting closer here, but  I think we should look at what
is going on in testRelative again.
essentially we have
try {

          positive case 1..
          positive case. 2..
          positive case  3...
         
          negative case ...
    } catch (SQLException sqle)
    {
           dumpSQLExceptions(sqle);

    }   

where dumpSQLException(sqle) now looks like this.
 static private void dumpSQLExceptions (SQLException se) {
                System.out.println("PASS -- expected exception");
                while (se != null) {
                       
System.out.println("SQLSTATE("+se.getSQLState()+"): "+se);  // really
should be se.getMessage()
                        se = se.getNextException();
                }
        }


So the goals , expanded this time a  little are
1)   Never print  stack trace for an expected exception
2)  Print the word PASS or EXPECTED for an expected exception.
3) Always print the SQLState and Message for any exception. (use
se.getMessaage() instead of just printing se)
4) Always print a stack trace for an unexpected exception.
5) Print the word FAIL for an unexpected exception.

In our test, yes the last test is a negative case and we do expect an
exception, and you took out the printStackTrace, so as long as things
are running fine the output is good and the test is good.  But let's
imagine that Kathey goes in next week and breaks testRelative for some
reason and  one of the positive test cases failed, what would I see in
my test output?  So if I went and broke this positive case:

                rs.relative(2);
               System.out.println("isFirst=" + rs.isFirst() + " isLast="
+ rs.isLast() + " isAfterLast=" + rs.isAfterLast());
               returnValue = rs.getString("name");
               System.out.println("Value="+returnValue);

I would see a diff, but it would say:
       PASS  -- expected exception ......
and I wouldn't see a trace.  So conditions would be satisfied for 1) ,
2) and 3) on our list but not for 4) and 5).

Really the bottom line is that we can't use the dumpSQLExceptions for
both failures and expected exceptions.
We are really going to have to separate out the negative exceptions. 
Our new  test might look something like this.

try {
          positive case  1...
          postive case   2..
          postive case   3..
          }
catch (SQLException sqle)
    {
          unexpectedException(sqle);
    }  


try {
       negative case 1 ...
    } catch SQLException(sqle)
    {
        // extra credit make expectedException take an SQLState and
check that the exception is the right one.
       expectedException(sqle)
    }
      
try {
    negative case 2
    } catch (SQLException sqle)
    {
       expectedException(sqle)
    }
}  

See examples the exception printing functions  in
functionTests/lang/casting for
    expectedException
    unexpectedException
    gotWrongException
  

Also take a look at the  statementExceptionExpected  method
lang/procedure.java. Since we need a separate try/catch block for each
negative case, this tests encapsolates all that.  Again I think it would
be nice to have it take a parameter for the expected SQLState that it
would check.


For our getting started series (and honestly for everybody)  it would be
terrific to to have  functional test template and then add variations of
these functions into functionTests/util/TestUtil.java for folks to
call.  It would add consistency, I am sure make conversion to a better
harness later easier, and again make life much easier for beginners.  
If you are interested, keep this task in the back of your mind.   Start
by making testRelative as perfect as you possibly can.  Later maybe you
can gut it for your template. 

Thanks

Kathey