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
Date Thu, 14 Jun 2007 21:51:01 GMT
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