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 Sat, 30 Jun 2007 18:44:02 GMT

 		After working for a long time to reflect some structural 
changes suggested by John and some refinement , for any additional 
suggestions/comments I am sending a small (sample) fixture.

 		public void testSchemaName() {
                          s.executeUpdate("set schema APP");
 			 s.executeUpdate("DECLARE GLOBAL TEMPORARY TABLE APP.t2(c21 int)
on commit delete rows not logged");
                                 fail("The qualifier for a declared global temporary table
must be SESSION");
                 catch(SQLException e)
                         assertSQLState("The qualifier for a declared global temporary table
name must be SESSION. " , "428EK" , e);


 		And How to handle the fixtures that require two connections.?

Thanks in Advance.

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