A mock container is still a container :) My point here was that adding "plain junit" support to the basic controls build project doesn't add a ton of value (if you know junit, just add it yourself), and that adding any kind of container-based tests (mock or otherwise) adds a bunch of complexity that I'm also not convinced belongs in a basic build. Personally, as a developer when I look at a new technology, the lower the apparent initial barrier to entry the more likely I am to dig deeper.
Note that a number of ppl have expressed interest in building a junit-based container for controls + associated build infrastructure. I'll be more than happy to review and submit any work people want to do in this area. > -----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 > >
