db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravinder Reddy <pand...@students.iiit.ac.in>
Subject Re: plzz help me w.r.t DERBY-2750
Date Thu, 28 Jun 2007 19:07:53 GMT

 	dear all,

 			assertSQLState() method takes 2 parameters out of 
which is one expected SQLState and Other is the Exception.how to handle 
this while it is uncommon to catch exceptions in JUnit.?
 		I am struggling in finding out the expected SQLStates for 
each SQL statement(group of sql statements) as the test 
(declareGlobalTempTableJava.java) has too many tests(nearly 2000 lines 
of code).
 		Thank U.

On Fri, 15 Jun 2007, Ravinder Reddy wrote:

> On Thu, 14 Jun 2007, Daniel John Debrunner wrote:
>> Ravinder Reddy wrote:
>>>     dear all,
>>>         I've been working on lang/declareGlobalTempTable.java for 
>>> converting it into
>>> junit.I have atttched the first patch to the issue (DERBY-2750).
>>>         This is the my First JUnit TestCase that I have ever written. I am 
>>> requesting  you to help me in enhancing my skills by reviewing my patch.
>>>         I have used only one Assertion Method (assertTrue()) and I have 
>>> put all the tests (around 50) in one fixture.I am getting some problems in 
>>> running the test case in linux(eclipse) but able to create patch using 
>>> eclipse.
>>>         As it is my first fixture , I think there is a great possibility 
>>> of learning more.
>> I would spend some time looking at the existing JUnit tests, eg. any class 
>> that extends for BaseJDBCTestCase.
>> A lot of utility methods have been added to keep tests as clean and simple 
>> as possible, thus allowing the reader to focus on what is being tested.
>> For example the use of a 'passed' variable and asserting it to be true only 
>> at the end of the fixture is not a common pattern in Junit. Typically 
>> assertions are in line, the first failure fails the fixture.
>> Catching exceptions tends to be somewhat uncommon, thanks to various 
>> utility methods, and if the fixture throws an exception the test will fail.
>> BaseJDBCTestCase is written to allow the common case of a test fixture 
>> needing a single connection to be written easily. Thus one doesn't (in that 
>> case) need to have any fields in the test class to hold a connection, the 
>> parent class does this. That connection is available using getConnection(), 
>> this means your code here:
>> +	protected void setUp() throws Exception {
>> +        	super.setUp();
>> +        	con1 = getConnection();
>> +        	con2 = getConnection();
>> is not doing what you think it is, but it is doing what the javadoc for 
>> getConnection() says. That is getConnection() returns the same connection 
>> object, thus con1 and con2 refer to the same object.
>> In fact I would say fields in JUnit classes tend to be rare, this is 
>> because they are not of much benefit. Each fixture when run is a separate 
>> instance of the class, thus if you have twenty fixtures putting the 
>> connection/statement in a field doesn't mean you have one 
>> connection/statement for all the fixtures, each fixture will create its own 
>> connection in its own instance field. This since such fields are only used 
>> by a fixture, it makes more sense just to hold the state as a local 
>> variable in that fixture.
>> It may also be worth creating a new class for the JUnit version of the 
>> test. This allows two things:
>>  1) The test name can follow the JUnit pattern of xxxxTest.java
>>  2) You don't have to convert the old test in one go. You can get one (or a 
>> small number) fixture working in the new class, submit that, get reviews 
>> and thus learn before having to convert a full test.
>>  3) It's easier to review :-)
>> Thanks for working on this.
>> Dan.
> 	Thank You Dan for your valuable comments/suggestions.
> 	 Upon careful Observation of Existing JUnit tests I came to know that
> many tests are using SQLState for asserting.For this we should know the 
> SQLState codes to compare with the Expected SQLState code in any assertion.
> n e way From where can I get The List of SQLState codes.
> Thank You.


    Every problem that has been solved can be solved again in a better way

                                                   - Ravinder Reddy


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

View raw message