Testing Persistence

Testing Persistence

Post by Cameron Zeme » Thu, 17 Jul 2003 00:29:42



How should you test the following (using DataAccessCommand pattern - Command
pattern for persistence):

public class ViewCart{
  private CachedRowSet rowSet = null;
  private int cartId;

  public void setCartId(int cartId){
    this.cartId = cartId;
  }

  public void execute() throws DataAccessException, LostConnectionException{
   Connection conn = null;
   PreparedStatement stat = null;
   try{
     Connection conn = ConnectionPool.getConnection();
     stat = conn.prepareStatement(VIEW_CART_QUERY);
     rowSet.populate(stat.executeQuery());
   }catch(SQLException e){
     throw new DataAccessException(e);
   }finally{
     try{ stat.close(); }catch(SQLException e){  }
     try{ stat.close(); }catch(SQLException e){  throw new
LostConnectionException(e);   }
   }
  }

  public String getProductName(){
    rowSet.getString("product_name");
  }
  // etc

Quote:}

 
 
 

Testing Persistence

Post by Robert C. Mart » Sat, 19 Jul 2003 04:29:38



written this on (or about)  Wed, 16 Jul 2003 01:29:42 +1000, :

Quote:>How should you test the following (using DataAccessCommand pattern - Command
>pattern for persistence):

>public class ViewCart{
>  private CachedRowSet rowSet = null;
>  private int cartId;

>  public void setCartId(int cartId){
>    this.cartId = cartId;
>  }

>  public void execute() throws DataAccessException, LostConnectionException{
>   Connection conn = null;
>   PreparedStatement stat = null;
>   try{
>     Connection conn = ConnectionPool.getConnection();
>     stat = conn.prepareStatement(VIEW_CART_QUERY);
>     rowSet.populate(stat.executeQuery());
>   }catch(SQLException e){
>     throw new DataAccessException(e);
>   }finally{
>     try{ stat.close(); }catch(SQLException e){  }
>     try{ stat.close(); }catch(SQLException e){  throw new
>LostConnectionException(e);   }
>   }
>  }

>  public String getProductName(){
>    rowSet.getString("product_name");
>  }
>  // etc
>}

The test should load some dummy rows and then invoke the ViewCard and
see if getProductName returns the correct data.  Then the test should
delete the dummy rows.

Why do you repeat the stat.close() statement?

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Testing Persistence

Post by Shane Mingin » Sat, 19 Jul 2003 13:16:41


Hi Robert

I was just reading a thread at
http://groups.yahoo.com/group/testdrivendevelopment where the OP was asking
about developing his persistence mechanism using TDD.  He was asking about
the chicken-egg problem of: if he is developing the Read command then does
he not need the Create command to help test it. (His words explain his
situation better
http://groups.yahoo.com/group/testdrivendevelopment/message/3361 )

So in this situation here would you use a CreateCart object to create the
dummy rows or would you write a method in the test that does the required
inserting?

I was just refactoring some of my persistence tests today ... I am using OJB
... and so to test that my Persistence.store(object) method was working
correctly, I was storing the object, then clearing the cache that OJB uses
to force a database read, and then using my  Persistence.get(objectName)
method to read back the object and check that all parts were there that
should be.

And as I was doing this I thought perhaps I should use some plain SQL and
JDBC to check that the object persisted to the database in the correct
manner?

What would you recommend?

Cheers
Shane

P.S.  I have just started reading the Craftsman story from SD Online.
http://www.sdmagazine.com/columnists/martin/  I like the style.  Have you
ever read any books by Eli Goldratt?  He is an Israeli physicist who has
some brilliant ideas on production and manufacturing processes.  Two I have
read and would recommend are: The Goal; and The Race. They present his ideas
and views in the form of a novel .  Not only are these (and his other) books
widely read but someone told me that they are also used as university texts.
So perhaps the Craftsman could one day become a fully-fledged novel ----
Alphonse would of course need a girlfriend, car, dog, obnoxious room mate,
overbearing mother .... etc *grin* ... maybe an anti-XP uncle <pick a name>
to discuss things with on Saturdays ;-)    ----- and become a standard text
at universities for software development?




> written this on (or about)  Wed, 16 Jul 2003 01:29:42 +1000, :

> >How should you test the following (using DataAccessCommand pattern -
Command
> >pattern for persistence):

> >public class ViewCart{
> >  private CachedRowSet rowSet = null;
> >  private int cartId;

> >  public void setCartId(int cartId){
> >    this.cartId = cartId;
> >  }

> >  public void execute() throws DataAccessException,

LostConnectionException{

- Show quoted text -

> >   Connection conn = null;
> >   PreparedStatement stat = null;
> >   try{
> >     Connection conn = ConnectionPool.getConnection();
> >     stat = conn.prepareStatement(VIEW_CART_QUERY);
> >     rowSet.populate(stat.executeQuery());
> >   }catch(SQLException e){
> >     throw new DataAccessException(e);
> >   }finally{
> >     try{ stat.close(); }catch(SQLException e){  }
> >     try{ stat.close(); }catch(SQLException e){  throw new
> >LostConnectionException(e);   }
> >   }
> >  }

> >  public String getProductName(){
> >    rowSet.getString("product_name");
> >  }
> >  // etc
> >}

> The test should load some dummy rows and then invoke the ViewCard and
> see if getProductName returns the correct data.  Then the test should
> delete the dummy rows.

> Why do you repeat the stat.close() statement?

> Robert C. Martin  | "Uncle Bob"

> PO Box 5757       | Tel: (800) 338-6716
> 565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
> Suite 135         |                               | www.XProgramming.com
> Vernon Hills, IL, | Training and Mentoring        | www.junit.org
> 60061             | OO, XP, Java, C++, Python     |

 
 
 

Testing Persistence

Post by Cameron Zeme » Sat, 19 Jul 2003 15:24:37


Quote:> >  public void execute() throws DataAccessException,

LostConnectionException{

Quote:> >   Connection conn = null;
> >   PreparedStatement stat = null;
> >   try{
> >     Connection conn = ConnectionPool.getConnection();
> >     stat = conn.prepareStatement(VIEW_CART_QUERY);
> >     rowSet.populate(stat.executeQuery());
> >   }catch(SQLException e){
> >     throw new DataAccessException(e);
> >   }finally{
> >     try{ stat.close(); }catch(SQLException e){  }
> >     try{ stat.close(); }catch(SQLException e){  throw new
> >LostConnectionException(e);   }
> >   }
> >  }

> >  public String getProductName(){
> >    rowSet.getString("product_name");
> >  }
> >  // etc
> >}

> The test should load some dummy rows and then invoke the ViewCard and
> see if getProductName returns the correct data.  Then the test should
> delete the dummy rows.

> Why do you repeat the stat.close() statement?

Woops, the second stat.close() is meant to be a conn.close()

Additionally when using the DataAccessCommand pattern I have
BaseQueryCommand and BaseUpdateCommand handle the getting and releasing of
database resources.

 
 
 

Testing Persistence

Post by Robert C. Mart » Sun, 20 Jul 2003 04:16:54



have written this on (or about)  Fri, 18 Jul 2003 16:16:41 +1200, :

Quote:>Hi Robert

>I was just reading a thread at
>http://groups.yahoo.com/group/testdrivendevelopment where the OP was asking
>about developing his persistence mechanism using TDD.  He was asking about
>the chicken-egg problem of: if he is developing the Read command then does
>he not need the Create command to help test it. (His words explain his
>situation better
>http://groups.yahoo.com/group/testdrivendevelopment/message/3361 )

>So in this situation here would you use a CreateCart object to create the
>dummy rows or would you write a method in the test that does the required
>inserting?

I've done it both ways.  If the CRUD implementation is simple enough
then using it in the tests is reasonable.  On the other hand, making
direct SQL calls in the tests is more direct and bypasses the
possibility of one error masking another.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Testing Persistence

Post by Malte Finsterwalde » Tue, 22 Jul 2003 04:18:35



>I was just refactoring some of my persistence tests today ... I am using OJB
>... and so to test that my Persistence.store(object) method was working
>correctly, I was storing the object, then clearing the cache that OJB uses
>to force a database read, and then using my  Persistence.get(objectName)
>method to read back the object and check that all parts were there that
>should be.

>And as I was doing this I thought perhaps I should use some plain SQL and
>JDBC to check that the object persisted to the database in the correct
>manner?

>What would you recommend?

What do you want to test?
Do you want to test that you can create an object and when you read it
later get the object back poperly? Then using create and read from the
object should do. If you want to make sure the database has a certain
format and has certain values, then you should user JDBC to test this.

So I would use the create, store and read methods from the object to
test that I get the object back properly. I don't care how this is
stored in the database, at least not in this test.

Greetings,
    Malte