Another way is to use the junit extension package
junit.extensions.TestSetup;
public static Test suite() {
TestSuite suite = new TestSuite(myClass);
TestSetup wrapper = new TestSetup(suite) {
protected void setUp() throws Error, Exception {
oneTimeSetUp();
}
protected void tearDown() throws Error, Exception {
oneTimeTearDown();
}
};
return wrapper;
}
Then, you define the static methods oneTimeSetup and oneTimeTearDown. In
oneTimeSetup, you initialize torque and in oneTimeShutdown, you shutdown
torque.
Bill
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
