db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Leng <wl...@metatomix.com>
Subject Re: JUnit + Torque
Date Wed, 07 Sep 2005 20:13:33 GMT
Another way is to use the junit extension package


   public static Test suite() {
     TestSuite suite = new TestSuite(myClass);
     TestSetup wrapper = new TestSetup(suite) {
       protected void setUp() throws Error, Exception {

       protected void tearDown() throws Error, Exception {

     return wrapper;

Then, you define the static methods oneTimeSetup and oneTimeTearDown. In 
oneTimeSetup, you initialize torque and in oneTimeShutdown, you shutdown 


Greg Monroe wrote:
>>does anybody know if any examples exist how to write a Junit test for
>>torque. I have a couple of Web Services which uses torque to access a
>>database. Thanks in advance for any ideas.
> I generally override the setup() method that JUnit supports and include
> the Torque
> setup lines.  E.g.:
> if ( ! Torque.isInit() ) {
>      Torque.init(torqueConfigFile);
> }
> The only "tricky" part is defining the config file location so that the
> JUnit is portable across
> developers, test machines.  Not a problem in my case since my app has a
> SystemConfiguration 
> object that know how to find things both online and off.  My test case
> setup methods just ask 
> this for the torque config file.
> To make repeatable testing in easier with torque, I run JUnit tests with
> a Torque properties file
> that points to a test database rather than my development DB.  I've got
> a "clean" state backup
> of this that can be restored as needed. This helps in two ways, first I
> use the test harness during
> development as a way to debug a section of code's logic. This can leave
> a lot of "garbage" in 
> the DB.  
> Second, many times a test requires some set of predefined records to run
> against.  For example,
> In order to test the code interactions between user information and
> group membership you probably 
> need a known set of users and memberships that can be used in
> determining success or failure.
> Have a predefined test database simplifies this (Ok test purists can
> start complaining now...).
> Oh, and one good general rule is for tests to attempt to clean up after
> themselves.  E.g., if they
> create records, they should attempt to delete them.  Sounds like a pain,
> but it actually help exercise
> the code better and makes you think a little more about how things are
> implimented.
> Good Luck.
> Greg
> Duke CE Privacy Statement
> Please be advised that this e-mail and any files transmitted with it are confidential
communication or may otherwise be privileged or confidential and are intended solely for the
individual or entity to whom they are addressed.  If you are not the intended recipient you
may not rely on the contents of this email or any attachments, and we ask that you  please
not read, copy or retransmit this communication, but reply to the sender and destroy the email,
its contents, and all copies thereof immediately.  Any unauthorized dissemination, distribution
or copying of this communication is strictly prohibited.

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message