The ability to run an existing JUnit test suite in the container is not currently supported by Cactus. The test must be a ServletTestCase.
If your test is run only in the container, then change the test superclass. If, on the other hand, the test is intended for execution both locally and remotely, then restructure the test class as follows: o Create a new non-TestCase exerciser class that holds the actual test routines. Change the TestCase assert calls to jUnit Assert assert calls. o Refactor the existing TestCase into a skeletal implementation that delegates to the exerciser. o Create a ServletTestCase that delegates to the same exerciser. There is a low-priority task on the Cactus todo list to enable running an existing JUnit test suite in the container . Cf. the http://www.mail-archive.com/cactus-user%40jakarta.apache.org/msg02944.ht ml thread for further details. Fred Loney Spirited Software, Inc. www.spiritedsw.com ----- Original Message ----- From: "White, Melissa" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 8:20 AM Subject: Cactus/Ant vs. JUnitEE > Hello - > > I currently have a set of JUnit tests that I run in my container (JRun) > because they require JNDI. I would like to integrate these tests into our > build (using Ant), so I've been trying to determine if Cactus would allow me > to do that. I have been reviewing the docs for a couple of days, and trying > to get something to work, but I'm still unclear as to whether this will even > be possible. > > The first approach I tried was to define the testTarget called by my > runservertests Ant task as follows: > > <target name="junit-persistence-tests" > depends="compile,prepare-testdirs"> > <junit printsummary="on" fork="true" haltonerror="true"> > <classpath> > <pathelement location="${portal.deploy}/classes" /> > <path refid="unittest.classpath" /> > </classpath> > <test name="com.triactive.test.CommonPersistenceTestDefinition" /> > </junit> > </target> > > com.triactive.test.CommonPersistenceTestDefinition defines the suite of > JUnit tests that need to run in the container (via the suite() method). > There is a setup step that is performed prior to running the tests using a > subclass of the JUnit TestSetup class. This step reads some data from files > and inserts it into the database. That works fine. Then, an attempt is made > to store an object in the JNDI directory that will be used by subsequent > tests. That's where I run into trouble. I get the following exception: > > [junit] javax.naming.NoInitialContextException: Need to specify class name > in environment or system property, or as an applet parameter, or in an > application resource file: java.naming.factory.initial > [junit] at > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:638) > [junit] at > javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241) > [junit] at > javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:2 78) > [junit] at > javax.naming.InitialContext.destroySubcontext(InitialContext.java:403) > [junit] at > com.triactive.test.PersistenceTestUtil.setTestCompany(PersistenceTestUti l.ja > va:41) > [junit] at > com.triactive.test.PersistenceTestSetup.setUp(PersistenceTestSetup.java: 63) > [junit] at junit.extensions.TestSetup$1.protect(TestSetup.java:18) > [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) > [junit] at junit.extensions.TestSetup.run(TestSetup.java:23) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe stRu > nner.java:231) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitT estR > unner.java:409) > > Does the test in my testTarget need to be a subclass of ServletTestCase or > one of the other Cactus TestCase types? If so, I'm confused about how I > would define that test to run my existing JUnit test suite in the container. > > Any help would be appreciated. I may be on the wrong track completely, but > the Cactus docs led me to think that this was something I should be able to > do. I was hoping I could use my existing test hierarchy to work within this > framework though. > > Thanks! Melissa > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
