You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Nicholas Lesiecki <ni...@eblox.com> on 2003/03/04 22:10:08 UTC

RE: Cactus/Ant vs. JUnitEE

Where is the InitialContext created in the original test case?

Cheers,
Nick

> -----Original Message-----
> From: White, Melissa [mailto:mwhite@triactive.com]
> Sent: Wednesday, February 26, 2003 1:26 PM
> To: 'Vincent Massol'; 'Cactus Users List'
> Subject: RE: Cactus/Ant vs. JUnitEE
>
>
> Vincent -
>
> Thank you very much for making this enhancement to Cactus!
> Unfortunately, I
> think I am still doing something wrong. My test still fails with the
> following exception when I attempt to use JNDI:
>
> 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
>
> Here is my TestCase, which attempts to run an existing TestCase
> (PersistenceTestDefinition) using the ServletTestSuite:
>
> public class ContainerTestCase extends TestCase
> {
>   public ContainerTestCase(String theName)
>   {
>     super(theName);
>   }
>
>   public static Test suite()
>   {
>     ServletTestSuite suite = new ServletTestSuite();
>     suite.addTest(PersistenceTestDefinition.suite());
>     return suite;
>   }
> }
>
> As you pointed out in an earlier message, on the server side I can use new
> InitialContext() to get the InitialContext. That is what I'm
> doing. However,
> the exception I'm getting indicates the code that is trying to get the
> InitialContext is not being executed within the container.
>
> -- Melissa
>
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Monday, February 24, 2003 8:37 AM
> To: 'Cactus Users List'
> Cc: mwhite@triactive.com
> Subject: RE: Cactus/Ant vs. JUnitEE
>
>
> Melissa,
>
> There's good news for you! I have implemented the required feature this
> week end and it's in Cactus 1.5 :-)
>
> Here's the way to run a pure JUnit Test on the server side, using
> Cactus:
>
> public class TestJUnitTestCaseWrapper extends TestCase
> {
>       public TestJUnitTestCaseWrapper(String theName)
>       {
>           super(theName);
>       }
>
>       public static Test suite()
>       {
>           ServletTestSuite suite = new ServletTestSuite();
>           suite.addTestSuite(TestJUnitTestCaseWrapper.class);
>           return suite;
>       }
>
>       public void testXXX()
>       {
>       }
> }
>
> You can of course put the suite() in a separate class so that you don't
> need to change a single line of your JUnit Test Case.
>
> BTW, I have uploaded a dev build of Cactus 1.5 on
> http://cvs.apache.org/builds/jakarta-cactus/nightly/2003-02-24/
> (normally this is delivered automatically by Gump every day but I'm
> still fighting to get this working).
>
> Thanks
> -Vincent
>
>
> > -----Original Message-----
> > From: White, Melissa [mailto:mwhite@triactive.com]
> > Sent: 20 February 2003 21:53
> > To: 'Cactus Users List'
> > Cc: 'vmassol@octo.com'; 'loney@spiritedsw.com'
> > Subject: RE: Cactus/Ant vs. JUnitEE
> >
> > Vincent -
> >
> > Thanks to you and Fred for the quick responses.
> >
> > We are currently using JUnitEE to execute this particular group of
> tests
> > that require JNDI. As far as I know, there isn't a way to execute
> JUnitEE
> > from Ant. At least, that's what I understand from some earlier posts
> to
> > this
> > list. I was hoping Cactus would provide a way to run these tests in
> their
> > current form as part of the build process. Based on the exception I'm
> > getting, I guess the test class specified in the test target for my
> > runservertests task is actually executing on the client side, since it
> is
> > not a subclass of one of the Cactus test types.
> >
> > In any case, we're looking at Cactus and the StrutsTestCase project to
> > expand our unit test coverage to include our Struts code and some non-
> > Struts
> > servlets and JSPs. I'll look forward to the addition of the capability
> in
> > Cactus to wrap existing JUnit TestCases and run them in the container
> as
> > well.
> >
> > Thanks! Melissa
> >
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.com]
> > Sent: Thursday, February 20, 2003 12:39 PM
> > To: 'Cactus Users List'
> > Cc: mwhite@triactive.com
> > Subject: RE: Cactus/Ant vs. JUnitEE
> >
> >
> > Hi Melissa,
> >
> > Cactus is much more than a simple JUnit Test Runner. It is a full
> fledge
> > unit testing framework for server side testing (it provides
> integration
> > with the container and gives you server objects that you can then use
> in
> > your test). If you are simply looking to run your existing tests
> inside
> > the container without changing them, then you should look at JUnitEE
> > (which is a pure JUnit Test Runner and not a testing framework).
> >
> > However, there are usually some differences between code that runs on
> > the client side and code that runs in the container. You mention JNDI.
> > On the server side, you would usually simply write "new
> > InitialContext()" to get the initial Context whereas on the client
> side
> > you need to specify the URL, credentials, etc of the JNDI directory.
> Of
> > course you could also define that for the server side, but then you
> > introduce unnecessary elements which you need to externalize, etc.
> >
> > Anyway, as Fred mentioned, we have a todo item to add the ability to
> > wrap existing JUnit Test Case and run them in the container.
> >
> > Hope it helps,
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: White, Melissa [mailto:mwhite@triactive.com]
> > > Sent: 19 February 2003 17:21
> > > To: 'cactus-user@jakarta.apache.org'
> > > 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
> > st
> > > Ru
> > > nner.java:231)
> > > [junit]     at
> > >
> >
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitT
> > es
> > > tR
> > > 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: cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>
>