db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: plzz help me..!!
Date Thu, 14 Jun 2007 18:08:12 GMT
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.

Mime
View raw message