To add to this a bit:

The value of the JUnit container here would be to test control
implementations which do not rely on any specific container context
(servelet, ejb, other custom containers, etc).  As Mike Foster stated,
this is should not be a mock object style container which simulates
another container.  A JUnit container should not be used for testing the
controls framework (ie, the pieces which end up in controls.jar).  I
think it is essential that we test the controls framework in the context
of the core Beehive controls clients; PageFlows and WebServices.  We
must be sure that controls work end-to-end within Beehive.

That all said, I agree with those who have stated that having a very
simple [junit] container would be very useful in helping users
understand controls, could simply parts of the docs, would be a good
example of what a control container is and how to make one, and would
get users going faster.

#!/zach

-----Original Message-----
From: Mike Foster 
Sent: Thursday, October 28, 2004 11:35 AM
To: Beehive Developers
Subject: RE: Blank controls app template checked in

FWIW, this isn't exactly the same as a mockobject style mock container.
It's really a new implementation of a control container.  It doesn't
simulate controls behavior in standard containers (Tomcat web/WLS
EJB/etc), but does give testers a way to exercise business logic in
controls without the overhead of a J2EE container.  I think it would be
valuable both as a means for exercising basic control code (not testing
container integration), and as an example of how to implement a controls
container.

-Mike

-----Original Message-----
From: Hoi Lam 
Sent: Thursday, October 28, 2004 9:36 AM
To: Beehive Developers
Subject: RE: Blank controls app template checked in


Great idea!  Mock containers will definitely make testing controls a lot
easier.  We should have a place for them, so control developers can shop
for one that fits their needs or contribute one if none is available.  

-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 28, 2004 6:41 AM
To: Beehive Developers
Subject: Re: Blank controls app template checked in

Kyle Marvin wrote:

>>I think users will find samples on how to test controls very valuable.
>>However, as Ken pointed out, most control tests require a container.
>>
>>    
>>
>
>I don't fully agree with this.  I think it is possible to provide a
'mock' container, in fact some of existing tests do exactly this.
Things like resource scope, external configuration, and other container
services can be mocked and provided by a test harness, that makes it
possible to examine how a control behaves w/out necessarily requiring a
you run w/in an actual server environment.
>
>A lot of it is a function of the control and the contextual services it
uses to do its job.  For example, a control could be written to run in
the web tier and have a dependency on a ServletContext contextual
service... you can certainly mock this too, but now the effort to create
the simulated runtime environment has gone up.  The more services the
control uses, the more effort exists to create a simulation of the
environment it needs.
>  
>
Yes, this is exactly I was hoping for.  I'll grant you that web tier 
controls are going to be a pain to test but there is a lot of ground in 
between there.  For example, I am writing a hibernate control. Building,

deploying, and manually testing just adds too many hours if all I want 
to do is test a query.  A lot of times (especially for new user) it can 
take 10 tries to get a single query right.  This can be 10 clicks of a 3

second JUnit test or 10 build/deploy/click+test stages - 30 seconds vs 
say 10-15 minutes (unless tomcat has sped up drastically recently...)?  
I've done both and I really really prefer the first :-).

Also, I imagine a mock container of sorts would be very helpful for the 
beehive build.  Kyle, which tests were you thinking of that provide a 
"mock" container?  Maybe I can help put together some stuff for this...

Thanks,

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://envoisolutions.com/people/dan



Reply via email to