db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: jdbcapi/testRelative intermittent diff
Date Tue, 19 Apr 2005 05:43:46 GMT
Hi Kathey,

Thanks for all the help on making this test as perfect as possible. 
Surely this would be a step in the righ direction.
Attached are the latest diffs that take care of your comments ( I hope 
;-) ).

~ Shreyas

Kathey Marsden wrote:

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

Mime
View raw message