RE: Server Side Testing ejb implementation code

["Bayly, Martin" <Ma...@webct.com>]

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:vmassol@pivolis.com]
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:Martin.Bayly@webct.com] 
Sent: 24 June 2003 19:56
To: cactus-user@jakarta.apache.org
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 

class not found error

[Bret Kumler <bk...@firstam.com>]

Ok, the script works on Windoze but not on UNIX, see below.

[qauser@srcbusd01 pm-tests]$ ant init
Buildfile: build.xml

init:
     [echo] ----------------------------------------------
     [echo] Cactus Classpath:
     [echo]
     [echo]
/home/qauser/faws-integration/third-party/cactus/lib/cactus-1.6dev-20030907.
jar:/home/qauser/faws-integration/third-party/cactus/lib/cactus-ant-1.6dev-2
0030907.jar:/home/qauser/faws-integration/third-party/cactus/lib/servletapi-
2.3.jar:/home/qauser/faws-integration/third-party/cactus/lib/j2ee-1-3-1.jar:
/home/qauser/faws-integration/third-party/cactus/lib/aspectjrt-1.0.6.jar:/ho
me/qauser/faws-integration/third-party/cactus/lib/commons-logging-1.0.3.jar:
/home/qauser/faws-integration/third-party/cactus/lib/commons-httpclient-2.0-
rc1.jar:/home/qauser/faws-integration/third-party/cactus/lib/junit-3.8.1.jar
:/home/qauser/faws-integration/third-party/cactus/lib/httpunit-1.5.3.jar:/ho
me/qauser/faws-integration/third-party/cactus/lib/nekohtml-0.7.4.jar
     [echo] ----------------------------------------------

BUILD FAILED
file:/home/qauser/faws-integration/pm-tests/build.xml:125: taskdef class
org.apache.cactus.integration.ant.CactusTask cannot be found

Total time: 1 second

Any ideas?