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 "Bayly, Martin" <Ma...@webct.com> on 2003/06/24 19:56:13 UTC
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
Re: Server Side Testing ejb implementation code
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hi Vincent,
No I don't have no patch to provide you for Session EJB testing. It was not a
criticism, just my general feeling and what I would like to see included in
Cactus.
BTW, I just found that there is some new content about that matter on the
website (I haven't read it for several months), and I'm very happy about it.
I'll look closely at it tomorrow at work.
Interresting thoughts about mock objects. Alright, I haven't used it a lot,
but once again it's so easy to deploy an EAR, so why bother? (Unless you're
working with Websphere, of course!!).
ok ok, I'll have to buy your book. Just one condition : can I have an
autograph?
:-P
Julien.
Le Dimanche 14 Septembre 2003 20:54, Vincent Massol a écrit :
> > -----Original Message-----
> > From: Julien Dubois [mailto:julien@julien-dubois.com]
> > Sent: 14 September 2003 20:43
> > To: Vincent Massol; 'Cactus Users List'
> > Subject: Re: Server Side Testing ejb implementation code
> >
> > Hi Vincent,
> >
> > I had a look at the "Cactus goals" page, and I've got some comments.
> >
> > 1. From my point of view, Cactus seems to be great for testing the
> > presentation layer of a J2EE application (servlets, JSPs, taglibs...).
> > But the thing that really interests me is Session EJB testing, as :
> >
> > - I'm using Struts. My JSPs are pretty simple (thanks Tiles & the
>
> several
>
> > third-party taglibs), and completly dumb (they just do presentation,
>
> no
>
> > logic). I don't need to write servlets or taglibs.
> >
> > - For the persistance layer I trust my app server (for entity beans)
>
> or
>
> > Hibernate.
> >
> > So as long as Session EJBs testing is not easy to do, I don't have
>
> much
>
> > use
> > for Cactus.
>
> Ok. Do you have a patch? ;-)
>
> > 2. Some of my applications do not have a presentation layer. Testing
>
> them
>
> > with
> > Cactus would be very difficult.
> >
> > 3. Mock objects are less and less useful. Using mock objects for
>
> testing
>
> > servlets could be interesing, but a complete app server is something a
>
> lot
>
> > more complicated. It's so easy to deploy your EAR in a real app
>
> server,
>
> > why
> > bother using mock objects??
>
> I don't agree. Mock Objects are extremely useful. The main benefit is
> when they are combined when the test-first approach. The test-first
> approach is still difficult to do with Cactus or any in-container
> testing solution as it is still too slow. Also, you need to be able to
> test your code without going all the way to the database. For several
> reasons: one of them being that the code may not be written yet. A
> second one is that you want your suite to pinpoint the exact cause of
> the problem when it breaks and not resort to debugging. Third of course
> is setup complexity (you need to set the database to the correct state
> even if you're testing some logic that has nothing to do with the
> database). Etc.
>
> <advertising>
> Hey, I'd suggest reading my JUnit in Action book
> (http://manning.com/massol) ;-)
> </advertising>
>
> > 4. I think using DbUnit with Cactus makes a lot of sense.
> > a. Because it is difficult to get a database in a known state by just
> > using
> > the EJBs.
> > b. Because sometimes the only way to validate a Session bean method is
>
> to
>
> > have
> > a look inside the database tables.
>
> Yep. This I cover in depth in chapter 11 of the book. For a simple
> example, see also the book source code on SourceForge:
> http://junitbook.sf.net.
>
> Thanks
> -Vincent
>
> > Just my 0.02 Euros.
> >
> > Julien.
> >
> > Le Dimanche 14 Septembre 2003 14:14, Vincent Massol a écrit :
> > > Hi Julien,
> > >
> > > Yes, ATM, there is a limitation in Cactus when it comes to testing
>
> EJBs.
>
> > > As we don't have an EJB redirector yet, we have to go through the
> > > remote/local interface. This is only the case for EJB. For all other
> > > types of J2EE components it works fine.
> > >
> > > Security roles should not be an issue. You have to decide what kind
>
> of
>
> > > test you want (functional or unit test). If you want to perform unit
> > > testing, then you want to test the fine-grained details of the code
> > > implementation. Simply do not use security in your deployment
> > > descriptors for cactus tests for example. Or create a valid EJB
>
> security
>
> > > context before calling the EJB to test.
> > >
> > > WRT form-based authentication, it is already implemented.
> > >
> > > Your "idea" of the "root" Session Bean is exactly what is planned!
> :
> :-)
> :
> > > See the todo page on the Cactus web site.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: Julien Dubois [mailto:julien@julien-dubois.com]
> > > > Sent: 24 June 2003 23:09
> > > > To: Cactus Users List
> > > > Subject: Re: Server Side Testing ejb implementation code
> > > >
> > > > Hi Martin, hi everybody,
> > > >
> > > > I'm a Cactus newbee too, and I'm having kind of the same problems.
>
> I'd
>
> > > > like to
> > > > tests my EJBs.
> > > >
> > > > Like Martin, I can only tests EJBs which are visible to the
>
> servlet
>
> > > > container,
> > > > and my Entity Beans are definitly not visible. This is not a major
> > > > problem,
> > > > my logic is in the Session Beans and they're the ones I'd like to
> > >
> > > test.
> > >
> > > > However, they're protected by a lot of different security roles,
>
> and I
>
> > > > find it
> > > > very difficult to test them from Cactus. Implementing form-based
> > > > authentication in Cactus would help (I see that is being worked on
>
> in
>
> > > the
> > >
> > > > CVS
> > > > tree), however it would not solve all my problems.
> > > >
> > > > So I'm toying with one idea :
> > > > Why not make a Session Bean, which would run as "root" (a
>
> unix-like
>
> > > "root"
> > >
> > > > role should exist), and which would inherit from
> > >
> > > junit.framework.TestCase?
> > >
> > > > It's just an idea, has anybody done something like that before??
> > > >
> > > > Julien Dubois.
> > > >
> > > > On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> > > > > 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: 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
RE: Server Side Testing ejb implementation code
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Julien Dubois [mailto:julien@julien-dubois.com]
> Sent: 14 September 2003 20:43
> To: Vincent Massol; 'Cactus Users List'
> Subject: Re: Server Side Testing ejb implementation code
>
> Hi Vincent,
>
> I had a look at the "Cactus goals" page, and I've got some comments.
>
> 1. From my point of view, Cactus seems to be great for testing the
> presentation layer of a J2EE application (servlets, JSPs, taglibs...).
> But the thing that really interests me is Session EJB testing, as :
>
> - I'm using Struts. My JSPs are pretty simple (thanks Tiles & the
several
> third-party taglibs), and completly dumb (they just do presentation,
no
> logic). I don't need to write servlets or taglibs.
>
> - For the persistance layer I trust my app server (for entity beans)
or
> Hibernate.
>
> So as long as Session EJBs testing is not easy to do, I don't have
much
> use
> for Cactus.
Ok. Do you have a patch? ;-)
>
> 2. Some of my applications do not have a presentation layer. Testing
them
> with
> Cactus would be very difficult.
>
> 3. Mock objects are less and less useful. Using mock objects for
testing
> servlets could be interesing, but a complete app server is something a
lot
> more complicated. It's so easy to deploy your EAR in a real app
server,
> why
> bother using mock objects??
I don't agree. Mock Objects are extremely useful. The main benefit is
when they are combined when the test-first approach. The test-first
approach is still difficult to do with Cactus or any in-container
testing solution as it is still too slow. Also, you need to be able to
test your code without going all the way to the database. For several
reasons: one of them being that the code may not be written yet. A
second one is that you want your suite to pinpoint the exact cause of
the problem when it breaks and not resort to debugging. Third of course
is setup complexity (you need to set the database to the correct state
even if you're testing some logic that has nothing to do with the
database). Etc.
<advertising>
Hey, I'd suggest reading my JUnit in Action book
(http://manning.com/massol) ;-)
</advertising>
>
> 4. I think using DbUnit with Cactus makes a lot of sense.
> a. Because it is difficult to get a database in a known state by just
> using
> the EJBs.
> b. Because sometimes the only way to validate a Session bean method is
to
> have
> a look inside the database tables.
Yep. This I cover in depth in chapter 11 of the book. For a simple
example, see also the book source code on SourceForge:
http://junitbook.sf.net.
Thanks
-Vincent
>
> Just my 0.02 Euros.
>
> Julien.
>
> Le Dimanche 14 Septembre 2003 14:14, Vincent Massol a écrit :
> > Hi Julien,
> >
> > Yes, ATM, there is a limitation in Cactus when it comes to testing
EJBs.
> > As we don't have an EJB redirector yet, we have to go through the
> > remote/local interface. This is only the case for EJB. For all other
> > types of J2EE components it works fine.
> >
> > Security roles should not be an issue. You have to decide what kind
of
> > test you want (functional or unit test). If you want to perform unit
> > testing, then you want to test the fine-grained details of the code
> > implementation. Simply do not use security in your deployment
> > descriptors for cactus tests for example. Or create a valid EJB
security
> > context before calling the EJB to test.
> >
> > WRT form-based authentication, it is already implemented.
> >
> > Your "idea" of the "root" Session Bean is exactly what is planned!
:-)
> > See the todo page on the Cactus web site.
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Julien Dubois [mailto:julien@julien-dubois.com]
> > > Sent: 24 June 2003 23:09
> > > To: Cactus Users List
> > > Subject: Re: Server Side Testing ejb implementation code
> > >
> > > Hi Martin, hi everybody,
> > >
> > > I'm a Cactus newbee too, and I'm having kind of the same problems.
I'd
> > > like to
> > > tests my EJBs.
> > >
> > > Like Martin, I can only tests EJBs which are visible to the
servlet
> > > container,
> > > and my Entity Beans are definitly not visible. This is not a major
> > > problem,
> > > my logic is in the Session Beans and they're the ones I'd like to
> >
> > test.
> >
> > > However, they're protected by a lot of different security roles,
and I
> > > find it
> > > very difficult to test them from Cactus. Implementing form-based
> > > authentication in Cactus would help (I see that is being worked on
in
> >
> > the
> >
> > > CVS
> > > tree), however it would not solve all my problems.
> > >
> > > So I'm toying with one idea :
> > > Why not make a Session Bean, which would run as "root" (a
unix-like
> >
> > "root"
> >
> > > role should exist), and which would inherit from
> >
> > junit.framework.TestCase?
> >
> > > It's just an idea, has anybody done something like that before??
> > >
> > > Julien Dubois.
> > >
> > > On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> > > > 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: 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
RE: Server Side Testing ejb implementation code
Posted by Vincent Massol <vm...@pivolis.com>.
It is! And it is documented at
http://jakarta.apache.org/cactus/writing/howto_ejb.html
In the future there'll be EJB redirectors.
Thanks
-Vincent
> -----Original Message-----
> From: Rajagopal. V [mailto:raja0576@yahoo.com]
> Sent: 14 September 2003 20:50
> To: Cactus Users List
> Subject: Re: Server Side Testing ejb implementation code
>
> Wouldnt it be easy to use JUnit Test Cases (like a
> standalone client application) that calls session
> ejbs.
> You can even write these test cases extending from
> Struts Test Case, something like
> public class TestBlah extends ServletTestCase {
> public void testAAA() {
> //Code to Test Session EJB Method AAA
> }
> .....
> }
>
> -Raj
>
> --- Julien Dubois <ju...@julien-dubois.com> wrote:
> > Hi Vincent,
> >
> > I had a look at the "Cactus goals" page, and I've
> > got some comments.
> >
> > 1. From my point of view, Cactus seems to be great
> > for testing the
> > presentation layer of a J2EE application (servlets,
> > JSPs, taglibs...).
> > But the thing that really interests me is Session
> > EJB testing, as :
> >
> > - I'm using Struts. My JSPs are pretty simple
> > (thanks Tiles & the several
> > third-party taglibs), and completly dumb (they just
> > do presentation, no
> > logic). I don't need to write servlets or taglibs.
> >
> > - For the persistance layer I trust my app server
> > (for entity beans) or
> > Hibernate.
> >
> > So as long as Session EJBs testing is not easy to
> > do, I don't have much use
> > for Cactus.
> >
> > 2. Some of my applications do not have a
> > presentation layer. Testing them with
> > Cactus would be very difficult.
> >
> > 3. Mock objects are less and less useful. Using mock
> > objects for testing
> > servlets could be interesing, but a complete app
> > server is something a lot
> > more complicated. It's so easy to deploy your EAR in
> > a real app server, why
> > bother using mock objects??
> >
> > 4. I think using DbUnit with Cactus makes a lot of
> > sense.
> > a. Because it is difficult to get a database in a
> > known state by just using
> > the EJBs.
> > b. Because sometimes the only way to validate a
> > Session bean method is to have
> > a look inside the database tables.
> >
> > Just my 0.02 Euros.
> >
> > Julien.
> >
> > Le Dimanche 14 Septembre 2003 14:14, Vincent Massol
> > a écrit :
> > > Hi Julien,
> > >
> > > Yes, ATM, there is a limitation in Cactus when it
> > comes to testing EJBs.
> > > As we don't have an EJB redirector yet, we have to
> > go through the
> > > remote/local interface. This is only the case for
> > EJB. For all other
> > > types of J2EE components it works fine.
> > >
> > > Security roles should not be an issue. You have to
> > decide what kind of
> > > test you want (functional or unit test). If you
> > want to perform unit
> > > testing, then you want to test the fine-grained
> > details of the code
> > > implementation. Simply do not use security in your
> > deployment
> > > descriptors for cactus tests for example. Or
> > create a valid EJB security
> > > context before calling the EJB to test.
> > >
> > > WRT form-based authentication, it is already
> > implemented.
> > >
> > > Your "idea" of the "root" Session Bean is exactly
> > what is planned! :-)
> > > See the todo page on the Cactus web site.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: Julien Dubois
> > [mailto:julien@julien-dubois.com]
> > > > Sent: 24 June 2003 23:09
> > > > To: Cactus Users List
> > > > Subject: Re: Server Side Testing ejb
> > implementation code
> > > >
> > > > Hi Martin, hi everybody,
> > > >
> > > > I'm a Cactus newbee too, and I'm having kind of
> > the same problems. I'd
> > > > like to
> > > > tests my EJBs.
> > > >
> > > > Like Martin, I can only tests EJBs which are
> > visible to the servlet
> > > > container,
> > > > and my Entity Beans are definitly not visible.
> > This is not a major
> > > > problem,
> > > > my logic is in the Session Beans and they're the
> > ones I'd like to
> > >
> > > test.
> > >
> > > > However, they're protected by a lot of different
> > security roles, and I
> > > > find it
> > > > very difficult to test them from Cactus.
> > Implementing form-based
> > > > authentication in Cactus would help (I see that
> > is being worked on in
> > >
> > > the
> > >
> > > > CVS
> > > > tree), however it would not solve all my
> > problems.
> > > >
> > > > So I'm toying with one idea :
> > > > Why not make a Session Bean, which would run as
> > "root" (a unix-like
> > >
> > > "root"
> > >
> > > > role should exist), and which would inherit from
> > >
> > > junit.framework.TestCase?
> > >
> > > > It's just an idea, has anybody done something
> > like that before??
> > > >
> > > > Julien Dubois.
> > > >
> > > > On Tuesday 24 June 2003 19:56, Bayly, Martin
> > wrote:
> > > > > 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
> > >
> >
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
Re: Server Side Testing ejb implementation code
Posted by "Rajagopal. V" <ra...@yahoo.com>.
Wouldnt it be easy to use JUnit Test Cases (like a
standalone client application) that calls session
ejbs.
You can even write these test cases extending from
Struts Test Case, something like
public class TestBlah extends ServletTestCase {
public void testAAA() {
//Code to Test Session EJB Method AAA
}
.....
}
-Raj
--- Julien Dubois <ju...@julien-dubois.com> wrote:
> Hi Vincent,
>
> I had a look at the "Cactus goals" page, and I've
> got some comments.
>
> 1. From my point of view, Cactus seems to be great
> for testing the
> presentation layer of a J2EE application (servlets,
> JSPs, taglibs...).
> But the thing that really interests me is Session
> EJB testing, as :
>
> - I'm using Struts. My JSPs are pretty simple
> (thanks Tiles & the several
> third-party taglibs), and completly dumb (they just
> do presentation, no
> logic). I don't need to write servlets or taglibs.
>
> - For the persistance layer I trust my app server
> (for entity beans) or
> Hibernate.
>
> So as long as Session EJBs testing is not easy to
> do, I don't have much use
> for Cactus.
>
> 2. Some of my applications do not have a
> presentation layer. Testing them with
> Cactus would be very difficult.
>
> 3. Mock objects are less and less useful. Using mock
> objects for testing
> servlets could be interesing, but a complete app
> server is something a lot
> more complicated. It's so easy to deploy your EAR in
> a real app server, why
> bother using mock objects??
>
> 4. I think using DbUnit with Cactus makes a lot of
> sense.
> a. Because it is difficult to get a database in a
> known state by just using
> the EJBs.
> b. Because sometimes the only way to validate a
> Session bean method is to have
> a look inside the database tables.
>
> Just my 0.02 Euros.
>
> Julien.
>
> Le Dimanche 14 Septembre 2003 14:14, Vincent Massol
> a �crit :
> > Hi Julien,
> >
> > Yes, ATM, there is a limitation in Cactus when it
> comes to testing EJBs.
> > As we don't have an EJB redirector yet, we have to
> go through the
> > remote/local interface. This is only the case for
> EJB. For all other
> > types of J2EE components it works fine.
> >
> > Security roles should not be an issue. You have to
> decide what kind of
> > test you want (functional or unit test). If you
> want to perform unit
> > testing, then you want to test the fine-grained
> details of the code
> > implementation. Simply do not use security in your
> deployment
> > descriptors for cactus tests for example. Or
> create a valid EJB security
> > context before calling the EJB to test.
> >
> > WRT form-based authentication, it is already
> implemented.
> >
> > Your "idea" of the "root" Session Bean is exactly
> what is planned! :-)
> > See the todo page on the Cactus web site.
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Julien Dubois
> [mailto:julien@julien-dubois.com]
> > > Sent: 24 June 2003 23:09
> > > To: Cactus Users List
> > > Subject: Re: Server Side Testing ejb
> implementation code
> > >
> > > Hi Martin, hi everybody,
> > >
> > > I'm a Cactus newbee too, and I'm having kind of
> the same problems. I'd
> > > like to
> > > tests my EJBs.
> > >
> > > Like Martin, I can only tests EJBs which are
> visible to the servlet
> > > container,
> > > and my Entity Beans are definitly not visible.
> This is not a major
> > > problem,
> > > my logic is in the Session Beans and they're the
> ones I'd like to
> >
> > test.
> >
> > > However, they're protected by a lot of different
> security roles, and I
> > > find it
> > > very difficult to test them from Cactus.
> Implementing form-based
> > > authentication in Cactus would help (I see that
> is being worked on in
> >
> > the
> >
> > > CVS
> > > tree), however it would not solve all my
> problems.
> > >
> > > So I'm toying with one idea :
> > > Why not make a Session Bean, which would run as
> "root" (a unix-like
> >
> > "root"
> >
> > > role should exist), and which would inherit from
> >
> > junit.framework.TestCase?
> >
> > > It's just an idea, has anybody done something
> like that before??
> > >
> > > Julien Dubois.
> > >
> > > On Tuesday 24 June 2003 19:56, Bayly, Martin
> wrote:
> > > > 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
> >
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Server Side Testing ejb implementation code
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hi Vincent,
I had a look at the "Cactus goals" page, and I've got some comments.
1. From my point of view, Cactus seems to be great for testing the
presentation layer of a J2EE application (servlets, JSPs, taglibs...).
But the thing that really interests me is Session EJB testing, as :
- I'm using Struts. My JSPs are pretty simple (thanks Tiles & the several
third-party taglibs), and completly dumb (they just do presentation, no
logic). I don't need to write servlets or taglibs.
- For the persistance layer I trust my app server (for entity beans) or
Hibernate.
So as long as Session EJBs testing is not easy to do, I don't have much use
for Cactus.
2. Some of my applications do not have a presentation layer. Testing them with
Cactus would be very difficult.
3. Mock objects are less and less useful. Using mock objects for testing
servlets could be interesing, but a complete app server is something a lot
more complicated. It's so easy to deploy your EAR in a real app server, why
bother using mock objects??
4. I think using DbUnit with Cactus makes a lot of sense.
a. Because it is difficult to get a database in a known state by just using
the EJBs.
b. Because sometimes the only way to validate a Session bean method is to have
a look inside the database tables.
Just my 0.02 Euros.
Julien.
Le Dimanche 14 Septembre 2003 14:14, Vincent Massol a écrit :
> Hi Julien,
>
> Yes, ATM, there is a limitation in Cactus when it comes to testing EJBs.
> As we don't have an EJB redirector yet, we have to go through the
> remote/local interface. This is only the case for EJB. For all other
> types of J2EE components it works fine.
>
> Security roles should not be an issue. You have to decide what kind of
> test you want (functional or unit test). If you want to perform unit
> testing, then you want to test the fine-grained details of the code
> implementation. Simply do not use security in your deployment
> descriptors for cactus tests for example. Or create a valid EJB security
> context before calling the EJB to test.
>
> WRT form-based authentication, it is already implemented.
>
> Your "idea" of the "root" Session Bean is exactly what is planned! :-)
> See the todo page on the Cactus web site.
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Julien Dubois [mailto:julien@julien-dubois.com]
> > Sent: 24 June 2003 23:09
> > To: Cactus Users List
> > Subject: Re: Server Side Testing ejb implementation code
> >
> > Hi Martin, hi everybody,
> >
> > I'm a Cactus newbee too, and I'm having kind of the same problems. I'd
> > like to
> > tests my EJBs.
> >
> > Like Martin, I can only tests EJBs which are visible to the servlet
> > container,
> > and my Entity Beans are definitly not visible. This is not a major
> > problem,
> > my logic is in the Session Beans and they're the ones I'd like to
>
> test.
>
> > However, they're protected by a lot of different security roles, and I
> > find it
> > very difficult to test them from Cactus. Implementing form-based
> > authentication in Cactus would help (I see that is being worked on in
>
> the
>
> > CVS
> > tree), however it would not solve all my problems.
> >
> > So I'm toying with one idea :
> > Why not make a Session Bean, which would run as "root" (a unix-like
>
> "root"
>
> > role should exist), and which would inherit from
>
> junit.framework.TestCase?
>
> > It's just an idea, has anybody done something like that before??
> >
> > Julien Dubois.
> >
> > On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> > > 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: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
RE: Server Side Testing ejb implementation code
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Julien,
Yes, ATM, there is a limitation in Cactus when it comes to testing EJBs.
As we don't have an EJB redirector yet, we have to go through the
remote/local interface. This is only the case for EJB. For all other
types of J2EE components it works fine.
Security roles should not be an issue. You have to decide what kind of
test you want (functional or unit test). If you want to perform unit
testing, then you want to test the fine-grained details of the code
implementation. Simply do not use security in your deployment
descriptors for cactus tests for example. Or create a valid EJB security
context before calling the EJB to test.
WRT form-based authentication, it is already implemented.
Your "idea" of the "root" Session Bean is exactly what is planned! :-)
See the todo page on the Cactus web site.
Thanks
-Vincent
> -----Original Message-----
> From: Julien Dubois [mailto:julien@julien-dubois.com]
> Sent: 24 June 2003 23:09
> To: Cactus Users List
> Subject: Re: Server Side Testing ejb implementation code
>
> Hi Martin, hi everybody,
>
> I'm a Cactus newbee too, and I'm having kind of the same problems. I'd
> like to
> tests my EJBs.
>
> Like Martin, I can only tests EJBs which are visible to the servlet
> container,
> and my Entity Beans are definitly not visible. This is not a major
> problem,
> my logic is in the Session Beans and they're the ones I'd like to
test.
>
> However, they're protected by a lot of different security roles, and I
> find it
> very difficult to test them from Cactus. Implementing form-based
> authentication in Cactus would help (I see that is being worked on in
the
> CVS
> tree), however it would not solve all my problems.
>
> So I'm toying with one idea :
> Why not make a Session Bean, which would run as "root" (a unix-like
"root"
> role should exist), and which would inherit from
junit.framework.TestCase?
> It's just an idea, has anybody done something like that before??
>
> Julien Dubois.
>
> On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> > 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: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
Re: Server Side Testing ejb implementation code
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hi Martin, hi everybody,
I'm a Cactus newbee too, and I'm having kind of the same problems. I'd like to
tests my EJBs.
Like Martin, I can only tests EJBs which are visible to the servlet container,
and my Entity Beans are definitly not visible. This is not a major problem,
my logic is in the Session Beans and they're the ones I'd like to test.
However, they're protected by a lot of different security roles, and I find it
very difficult to test them from Cactus. Implementing form-based
authentication in Cactus would help (I see that is being worked on in the CVS
tree), however it would not solve all my problems.
So I'm toying with one idea :
Why not make a Session Bean, which would run as "root" (a unix-like "root"
role should exist), and which would inherit from junit.framework.TestCase?
It's just an idea, has anybody done something like that before??
Julien Dubois.
On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> 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
RE: Server Side Testing ejb implementation code
Posted by Vincent Massol <vm...@pivolis.com>.
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... Thats 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