XpdWiki
| FrontPage |
| RecentChanges |
| XtC |
| FindPage |
| PageIndex |
| XpApprentices |
UserPreferences
Edit this page
Referenced by
XPInPractice
WelcomeToOT2000Vi...
TestDatabaseStoredProcedures |
|
| Your trail: | |
Your software needs to read and write to a database as part of integration with existing software.
How do you as an XP developer test this?
Let's use the example of a database table maintaining subscribers to a fictitious TV cable channel called 'XPnet'. This table stores subscriber name and address using a key of name, postcode and subscription date.
Test access to ResultSet?
* Assuming you are using SQL, results will be supplied in a ResultSet?. * Create a dummy result set for use by your code, sample code to be supplied?. * Write one test which expects an SQLException for every call to ResultSet?.
Test vanilla methods on your domain classes * Create objects, e.g: Subscriber, to represent the information you wish to store. * Write a test to create an example Subscriber and exercise your interaction with it.
String name = "Programmer, X"; String postCode = "XP1 2RS"; Date subscibeOn = 19990101; Subscriber aPerson = new Subscriber( name, postCode, subscribeOn ); assert( "getName should retrieve original name",aPerson.getName().equals( name ) ); // etc..
Test database can be accessed * Simply test that the pipework works ... more to add here? * Write a test where the database connection, e.g: JDBC, fails - perhaps use an incorrect db name.
Test consequences of database updates * An insert,delete or update to the database often has consequences when your program later reads the table. * Write one test which proves each consequence. E.g: You've just deleted a Subscriber. Test how your program copes when it next reads this Subscriber. Typically tests like this need helper methods to create the scenario, e.g: * setUp() may delete all rows for the test date. * setUp() might insert rows into a table for your test, and tearDown() remove them after. * Consider creating test tables, just like the real ones, for your purpose. Populate them with simple data or copy rows from the real tables. Change your table view to point to the other table(s). * Remember: your objective is to have discrete repeatable tests.
Sample code here ... e.g: Dummy Result Set
Conclusion Testing stored procedures can be achieved by testing each layer; your domain classes, result sets, database interaction and consequences of the stored procedures. ³TestDatabaseStoredProcedure
| Edit this page More info... Attach file... |
| This page last changed on 14-Apr-2000 11:30:58 BST by unknown. |