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.
