Topic: Database Operations Tests !!!!

Message

   Testing J2EE applications is often difficult and time-consuming at best, but 
testing the database operations portion of a J2EE application is especially 
challenging. Database operations tests must be able to catch logic errors—when a 
query returns the wrong data, for example, or when an update changes the 
database state incorrectly or in unexpected ways.

For example, say you 
have a USER class that represents a single USER table and that database 
operations on the USER table are encapsulated by a Data Access Object (DAO), 
UserDAO, as follows:

public interface UserDAO {

/** * Returns the 
list of users 

* with the given name

* or at least the minimum 
age

*/

public List listUsers(String name, Integer 
minimumAge);

/**

* Returns all the users

* in the 
database

*/

public List listAllUsers();

}

In this 
simple UserDAO interface, the listUsers() method should return all rows (from 
the USER table) that have the specified name or the specified value for minimum 
age. A test to determine whether you've correctly implemented this method in 
your own classes must take into consideration several questions:

* Does 
the method call the correct SQL (for JDBC applications) or the correct 
query-filtering expression (for object role modeling [ORM]-based 
applications)?
* Is the SQL- or query- filtering expression correctly 
written, and does it return the correct number of rows?
* What happens if you 
supply invalid parameters? Does the method behave as expected? Does it handle 
all boundary conditions appropriately?
* Does the method correctly populate 
the users list from the result set returned from the database?

Thus, even 
a simple DAO method has a host of possible outcomes and error conditions, each 
of which should be tested to ensure that an application works correctly. And in 
most cases, you'll want the tests to interact with the database and use real 
data—tests that operate purely at the individual class level or use mock objects 
to simulate database dependencies will not suffice. Database testing is equally 
important for read/write operations, particularly those that apply many changes 
to the database, as is often the case with PL/SQL stored procedures.

Author	Message
tanushree Senior Member Joined: 04Apr2007 Online Status: Offline Posts: 2160	Topic: Database Operations Tests !!!! Posted: 06Oct2007 at 1:08am
	Testing J2EE applications is often difficult and time-consuming at best, but testing the database operations portion of a J2EE application is especially challenging. Database operations tests must be able to catch logic errors—when a query returns the wrong data, for example, or when an update changes the database state incorrectly or in unexpected ways. For example, say you have a USER class that represents a single USER table and that database operations on the USER table are encapsulated by a Data Access Object (DAO), UserDAO, as follows: public interface UserDAO { /** * Returns the list of users * with the given name * or at least the minimum age / public List listUsers(String name, Integer minimumAge); /* * Returns all the users * in the database / public List listAllUsers(); } In this simple UserDAO interface, the listUsers() method should return all rows (from the USER table) that have the specified name or the specified value for minimum age. A test to determine whether you've correctly implemented this method in your own classes must take into consideration several questions: Does the method call the correct SQL (for JDBC applications) or the correct query-filtering expression (for object role modeling [ORM]-based applications)? * Is the SQL- or query- filtering expression correctly written, and does it return the correct number of rows? * What happens if you supply invalid parameters? Does the method behave as expected? Does it handle all boundary conditions appropriately? * Does the method correctly populate the users list from the result set returned from the database? Thus, even a simple DAO method has a host of possible outcomes and error conditions, each of which should be tested to ensure that an application works correctly. And in most cases, you'll want the tests to interact with the database and use real data—tests that operate purely at the individual class level or use mock objects to simulate database dependencies will not suffice. Database testing is equally important for read/write operations, particularly those that apply many changes to the database, as is often the case with PL/SQL stored procedures. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Beginners @ OneStopTesting