Good solution, Vincent! Easy and effective.
Is it possible to include a different test case in the suite? E.g.
LocalTest.java:
public class LocalTest extends TestCase {
// standard JUnit test case
}
ContainerTest.java:
public class ContainerTest extends TestCase {
public static Test suite() {
ServletTestSuite suite = new ServletTestSuite();
suite.addTestSuite(LocalTest.class);
return suite;
}
}
Fred Loney
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: "'Cactus Users List'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, February 23, 2003 10:08 AM
Subject: RE: Single test class for both local and remote
> Done! It is now possible to run pure JUnit tests on the server side
> using Cactus :-)
>
> Here is an example:
>
> 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()
> {
> }
> }
>
> Hope you like it (it took me a good part of the afternoon! :-)).
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Fred Loney [mailto:[EMAIL PROTECTED]
> > Sent: 23 February 2003 00:46
> > To: Cactus Users List
> > Subject: Re: Single test class for both local and remote
> >
> > I suspect that JUnitEE is a preferable vehicle for satisfying this
> > particular requirement, but I'm not qualified to judge. If it is
> > desirable to support the requirement in cactus, then the only way I
> know
> > to accomplish option 2b using TestCase objects rather than
> > CactusTestCase objects is to preprocess the client source with
> aspectj.
> > This alternative does indeed entail additional user set-up. But
since
> > cactus is essentially an aspect, it is not unreasonable to offer
> cactus
> > functionality as an aspect.
> >
> > It would then be straightforward to wrap the aspect in a separate
> > CactusTestCase class so that the user can have it both ways. Thus,
the
> > Cactus distro would include:
> >
> > 1) a CactusAspect ajc aspect that can be used to introduce cactus
> > functionality into an arbitrary JUnit TestCase class, and
> >
> > 2) a CactusTestCase java class that is merely a shell processed by
the
> > CactusAspect.
> >
> > In order to use (1), the user integrates CactusAspect into his build
> as
> > desired.
> >
> > In order to use (2), the user extends CactusTestCase rather than
> > TestCase and sets the "cactus.type" system parameter as you
describe.
> >
> > CactusTestCase delegates to an appropriate aspect based on the
> > cactus.type value. Since CactusTestCase delegates to the aspect,
there
> > is no duplicate effort in the cactus project.
> >
> > Users who are comfortable using an aspect will opt for (1). Users
who
> > aren't will opt for (2).
> >
> > I am not clear about the usage model for (2). E.g. I currently have
an
> > ant task for local tests, an ant task for cactus tasks, and an ant
> task
> > that runs both of these subtasks sequentially. Would I be able to
> retain
> > this setup? The ability to run all tests in a single ant task is
> > important.
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > To: "'Cactus Users List'" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Saturday, February 22, 2003 6:06 AM
> > Subject: RE: Single test class for both local and remote
> >
> >
> > > Hi Fed,
> > >
> > > > -----Original Message-----
> > > > From: Fred Loney [mailto:[EMAIL PROTECTED]
> > > > Sent: 05 February 2003 20:03
> > > > To: Cactus Users List
> > > > Subject: Re: Single test class for both local and remote
> > > >
> > > > The design goal should be to execute a vanilla JUnit TestCase in
a
> > web
> > > > container without a rebuild or reconfiguration. If the
> > > ServletTestSuite
> > > > in option 2b consisted of TestCase objects rather than
> > CactusTestCase
> > > > objects, that would be preferable.
> > >
> > > Yeah, except that I haven't figured out yet how it could work...
> (I'm
> > > not even sure it is possible using the JUnit framework - I'll need
> to
> > > dive into the Junit source code a bit more though to verify this).
> > >
> > > >
> > > > Stepping back, this problem is an ideal example of an aspect:
> Cactus
> > > > behavior is introduced at strategic cutpoints without
modification
> > to
> > > > the source code. An alternative, then, is to provide a Cactus
> aspect
> > > > rather than a new Cactus class. The developer is then free to
use
> > the
> > > > Cactus aspect in whatever way fits his usage model. E.g.:
> > > >
> > > > In app:
> > > >
> > > > test.local.MyTestCase extends TestCase {
> > > > ... // test methods
> > > > }
> > > >
> > > > test.web.MyServletTestCase extends MyTestCase {
> > > > // no test methods
> > > > }
> > > >
> > > > In Cactus distribution:
> > > >
> > > > aspect Cactus {
> > > > ... // Cactus behavior introduced into TestCase method
calls
> > > > }
> > > >
> > > > In Ant build:
> > > >
> > > > <target name="server-testbed">
> > > > <ajc ... >
> > > > <src>
> > > > <pathelement location="/tools/cactus/Cactus.ajc"/>
> > > > <pathelement location="${source}/test/web"/>
> > > > </src>
> > > > </ajc>
> > > > </target>
> > > >
> > > > This alternative enables a number of approaches for enabling
> Cactus
> > > > rather than stipulating a single mechanism.
> > > >
> > > > Note that the Cactus aspect described here is dynamic; it is not
> > > > equivalent to a static aspect that changes the superclass from
> > > TestCase
> > > > to ServletTestCase.
> > > >
> > >
> > > The idea sounds interesting but I'm not sure if I understand
> > correctly.
> > > I can see 2 issues:
> > >
> > > 1/ If the aspect is part of the Cactus source code, then we'll
need
> to
> > > deliver our own junit jar as the aspect would need to be weaved
> > > statically into the junit code (either sources or bytecode with
> > AspectJ
> > > 1.1). Otherwise we would only be able to catch calls to JUnit,
which
> > we
> > > can already do using standard java code.
> > >
> > > 2/ If the aspect is something to be used by the user, then the
issue
> > is
> > > that it will complexify greatly the setup for the user who will
need
> > to
> > > have AspectJ, set up his build, etc. I don't think this will be
> > > acceptable.
> > >
> > > Please tell me if there's something I don't understand.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > Fred Loney
> > > >
> > > > ----- Original Message -----
> > > > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > > > To: "'Cactus Users List'" <[EMAIL PROTECTED]>
> > > > Cc: <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, February 05, 2003 1:49 AM
> > > > Subject: RE: Single test class for both local and remote
> > > >
> > > >
> > > > > Hi Fred,
> > > > >
> > > > > I have thought this morning about how to offer the "offline"
> > feature
> > > > for
> > > > > Cactus. I think it is possible relatively easily. Here's a
> > proposal
> > > > > below. Tell me what you think of it. If you think it will
solve
> > your
> > > > > usecase, I'll make a formal proposal with more details.
> > > > >
> > > > > Proposal:
> > > > >
> > > > > * 3 ways to write a Cactus test case:
> > > > > 1/ MyTestClass extends ServletTestCase (or JspTestCase,
etc).
> > This
> > > > is
> > > > > the same a now
> > > > > 2/ MyTestClass extends CactusTestCase, and:
> > > > > a/ it needs a "suite()" method such as:
> > > > >
> > > > > public static void suite()
> > > > > {
> > > > > TestSuite suite = new ServletTestSuite();
> > > > > // or JspTestSuite(), etc.
> > > > >
> > > > > // For a pure Junit test
> > > > > // TestSuite suite = new TestSuite();
> > > > >
> > > > > suite.add(new TestTest("testPassed"));
> > > > > suite.add(new TestTest("testFailed"));
> > > > > suite.add(new TestTest("testErrored"));
> > > > > return suite;
> > > > > }
> > > > >
> > > > > b/ there is no suite() method but the "cactus.type" system
> > > > parameter
> > > > > is passed to the JUnit Test Runner JVM. Its possible values
are:
> > > > > "servlet", "jsp", "filter" or "none" (can also be called
> "junit").
> > > The
> > > > > last one is a pure junit test. The advantage of b/ is that the
> > > choice
> > > > of
> > > > > offline/online is decided externally to the test case. It may
> make
> > > > sense
> > > > > for some cases, such as the one you mention, Fred.
> > > > >
> > > > > I won't enter in the details of the implementation but I think
I
> > > have
> > > > > thought them out and it may work.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Fred Loney [mailto:[EMAIL PROTECTED]
> > > > > > Sent: 05 February 2003 07:01
> > > > > > To: Cactus Users List
> > > > > > Subject: Re: Single test class for both local and remote
> > > > > >
> > > > > > The reason for the todo item is local/server regression
> testing.
> > > The
> > > > > > application framework I use insulates most of the code from
> the
> > > > > > container context. Thus, one can code and test locally
> quickly,
> > > then
> > > > > > occasionally deploy and test on the server using the same
code
> > > base.
> > > > > >
> > > > > > The only hitch is that the test case must derive from
> > > > ServletTestCase
> > > > > > for server testing. The work-around I use is to pair a small
> > > > TestCase
> > > > > > with a small ServletTestCase, both of which do nothing more
> than
> > > > > > delegate to a common test exerciser object.
> > > > > >
> > > > > > It is not clear that the todo item that I initiated is
> > necessary,
> > > > > > although there might be other uses. It would be worthwhile
to
> > keep
> > > > the
> > > > > > item open for a while.
> > > > > >
> > > > > > Fred Loney
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > > > > > To: "'Cactus Users List'" <[EMAIL PROTECTED]>
> > > > > > Sent: Tuesday, February 04, 2003 12:47 AM
> > > > > > Subject: RE: Single test class for both local and remote
> > > > > >
> > > > > >
> > > > > > > Hi Tim,
> > > > > > >
> > > > > > > Yes, it may make sense in some situations. This is why
we've
> > > added
> > > > a
> > > > > > new
> > > > > > > todo in the Cactus todo list
> > > > > > > (http://jakarta.apache.org/cactus/todo.html) about:
> > > > > > >
> > > > > > > "Ability to write Cactus tests by extending normal JUnit
> > > TestCase
> > > > > > > instead of Cactus extensions (by using special Cactus
> > TestSuite
> > > > > > > objects). This will allow to easily execute the same test
> > > outside
> > > > > and
> > > > > > > inside of the container (for test not depending on
container
> > > > > objects).
> > > > > > > Idea suggested by <link
> > href="mailto:[EMAIL PROTECTED]">Fred
> > > > > > > Loney</link>."
> > > > > > >
> > > > > > > Now, for your problem at hand, what would be the issue
about
> > > > running
> > > > > > > both the remote and local EJB class from a
ServletTestCase?
> Is
> > > it
> > > > a
> > > > > > > question of speed only?
> > > > > > >
> > > > > > > Thanks
> > > > > > > -Vincent
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tim McNerney [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: 04 February 2003 01:00
> > > > > > > > To: [EMAIL PROTECTED]
> > > > > > > > Subject: Single test class for both local and remote
> > > > > > > >
> > > > > > > > I want to build a test which works both locally (on the
> > client
> > > > > side)
> > > > > > > and
> > > > > > > > remotely (on the server side). This is basically testing
> the
> > > > local
> > > > > > and
> > > > > > > > remote interfaces of an EJB. Since much of the code
would
> be
> > > the
> > > > > > same
> > > > > > > > for both, I'd like to keep it in one class. Let's say
I'm
> > > using
> > > > > > > > (extending) a ServletTestCase for the server side test.
Is
> > > there
> > > > > > some
> > > > > > > > way for me to tell my test class not to connect to the
> test
> > on
> > > > the
> > > > > > > > server side but simply run the test locally?
> > > > > > > >
> > > > > > > > And I'm making any sense?
> > > > > > > >
> > > > > > > > --Tim
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > > 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]
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > 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]
> > > > >
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
