I'm not so sure. I think class visibility does matter. Maybe I'm not understanding
you (or you're not understanding me :) )
For example, we have data access (DAO) classes that are only deployed in the EJB jar
file, because they are an implementation detail of the EJB.
However, we want to use Cactus to unit test these DAO classes directly.
e.g.
public void testDAO() {
MYDAOClass instance = new MyDAOClass();
MyResult result = instance.methodToTest(param1);
// assert results
assertXXX[_];
}
The problem is that when we deploy, the testcase gets deployed to the web tier (so
that it can be called by the cactus servlet redirector, but the dao class only gets
deployed to the EJB jar.
Currently, our development build uses an exploded WAR format, but jar'd EJBs and its
not using an EAR.
We're using WebLogic which (I think), in this configuration, loads the WAR and EJBs in
sibling class loaders. This means that the Test class (in the web tier) cannot see the
DAO class(in the EJB jar).
I realize that this is paricular to the way we are deploying, and that other
deployment schemes might get around this issue, but my basic point was that in an
environment where you want to limit the visibility of certain classes through the use
of class loading schemes, it becomes difficult to test the classes that are not
normally visible from the web tier, because Cactus depends upon the web tier (the
redirector servlet) being able to see the test cases and therefore the classes under
test.
I was wondering if anyone had come across this issue before, and had come up with a
good solution. The only solution I can see at the moment, is to deploy differently
when creating a build that needs to run cactus tests. But this seems inappropriate,
as then our development build is too different to our production build, so other
testing and the general running of the app may be compromised. e.g. someone may write
some regular domain code which depends on the class loader configuration set up in the
development build, and that code would fail to run in the production build.
Sorry if I'm not making this very clear.
Thanks
Martin
-----Original Message-----
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: September 14, 2003 5:10 AM
To: 'Cactus Users List'
Cc: Bayly, Martin
Subject: RE: Server Side Testing ejb implementation code
Hi Martin,
In that regards, Cactus works in the same way than JUnit does. Whatever
your class to unit test is, do the following:
public void testXXX()
{
MyClassToTest instance = new MyClassToTest();
// whatever else needs to be set up
MyResult result = instance.methodToTest(param1, ..., paramN);
// asserts results
assertXXX[...]
}
EJB visibility or any other class visibility does not matter at all.
Cactus is about unit testing, not functional testing, thus you are not
hindered whether the class is visible remotely or not... That's the
beauty of it ;-)
Hope it helps,
-Vincent
-----Original Message-----
From: Bayly, Martin [mailto:[EMAIL PROTECTED]
Sent: 24 June 2003 19:56
To: [EMAIL PROTECTED]
Subject: Server Side Testing ejb implementation code
Hi
We're looking into using Cactus to improve integration unit testing.�
We're planning on using Cactus primarily for testing our ejb interfaces,
but ideally we'd like to use it for server side testing of lower level
classes in the ejb implementations e.g. data access classes for example.
This raises the issue of visibility of those classes to the web tier
where the cactus unit tests run.
Currently, our deployed build is pretty loose and everything can see
pretty much everything else.� However, we're in the process of
tightening this up with the intention being that the web tier will only
be able to see the ejb interfaces and the classes exposed by those
interfaces.� However, it won't 'conceptually' be able to see ejb
implementation details.
To a certain extent this depends on the class loading scheme used by the
container - we're currently using weblogic 6 and in the current weblogic
class loading scheme the web app can see all the classes in the ejb, as
all ejbs are loaded using a single class loader, and the web app is
loaded as a child class loader of the ejb class loader.
However, we don't particularly want to be tied to the current weblogic
scheme.
I was just wondering if other people have come across this issue and how
have they tackled it.� Does it mean we're going to have to deploy with a
different structure for running server unit tests?� I was kind of hoping
the only difference in our test/production build would be the deployed
test cases and cactus jars.
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
