On Fri, 4 Oct 2002, Taylor, Jason wrote:
> Date: Fri, 4 Oct 2002 12:49:21 -0700
> From: "Taylor, Jason" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Applying patches
>
> I think you're right-- it's best to keep all the info about a bug in one
> place.
>
> What else could we associate with the bug to help out committers? Is there
> a preferred format for unit tests? Struts has a bunch of different facets,
> maybe there would be several different formats that would make sense.
>
Struts currently has two testing environments, to reflect the fact that
some things can be tested statically, and some really need to be done in
the environment of a running servlet container.
For static unit tests, we use the JUnit framework <http://www.junit.org>
(current version 3.7). The sources for these tests are in the "src/test"
hierarchy in the CVS repository, and are executed via the "test.junit"
target in the top-level build.xml file. Such tests are focused on the
low-level functionality of individual methods, are are particularly
suitable for the static methods in the org.apache.struts.util utility
classes. In the test hierarchy, there are also some "mock object" classes
(in the org.apache.struts.mock package) so that you can package up things
that look like servlet API and Struts API objects to pass in as arguments
to such tests.
This works fairly well for exercising most method-level stuff, but does
not really address situations of dynamic behavior -- most particularly the
execution of custom tags for Struts. You can try to fake what a JSP
container does, but a much more reliable testing regime would actually
execute the tag in a real container. For that purpose, we use the Cactus
testing framework <http://jakarta.apache.org/cactus>, which re-executes
the JUnit-based tests as well to make sure that nothing bad happens when
you switch environments. Right now, there are very few dynamic tests;
ideally, we will have tests for every tag, that cover every reasonable
combination of tag attribute values (yes, that's a tall order -- the
totally lines of test source code will undoubtedly exceed the totally
lines of code in the framework itself if we achieve this).
> Fears about regression issues are well-founded. What do people think about
> including a version of the example application that uses the patch, and
> updating the example as a way of maintaining a "reference" integration
> testbed? That way, you'd be able to assess the impact of patches on each
> other to some degree. Just a thought.
>
The struts-example app is primarily there to help people learn how to
develop using Struts, so we probably should not obfuscate it. However,
the exercise-taglib webapp might be a useful place to build tests off of
-- these pages can be run manually by users or developers investigating a
particular tag, or automatically by the testing regime that validates
behavior by looking at the output that is produced.
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 12:04 PM
> To: Struts Developers List
> Subject: RE: Applying patches
>
>
>
>
> On Fri, 4 Oct 2002, Taylor, Jason wrote:
>
> > Date: Fri, 4 Oct 2002 11:23:39 -0700
> > From: "Taylor, Jason" <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: 'Struts Developers List' <[EMAIL PROTECTED]>
> > Subject: RE: Applying patches
> >
> > I suppose you could log a bug that refers to a patch of another bug, if
> that
> > isn't too weird. That way, you could vote for a bug you want fixed and
> you
> > could vote for a patch that fixes it separately and the severity of the
> > problem could be tracked along with the relative confidence people have in
> > proposed solution. The trick would be making it easy to get rid of the
> > patch votes when a bug is resolved. Anyone out there a bugzilla wizard?
> >
>
> Votes go away automatically when an issue is FIXED, so that's not a
> problem. I can also adjust the vote parameters on Struts bug reports,
> which are currently:
>
> * Maximum votes per person = 6
>
> * Maximum votes per person on a single bug = 3
>
> if we want to.
>
> Personally, I'd prefer that alternative patches to the same problem be
> attached to the same bug report -- it's a lot easier to keep things
> straight that way -- and arguments for or against particular fix
> approaches can be made in your notes on the bug report and/or on
> STRUTS-DEV.
>
> Craig
>
>
> > -----Original Message-----
> > From: Scott Carlson [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 11:08 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Applying patches
> >
> >
> > - Maybe we should start a discussion on using the Voting in bugzilla?
> > Although
> > that is meant for prioritizing
> > - Or maybe a "+1 I tried it" in the comments to help committers feel more
> > comfortable.
> >
> >
> > I am one of those people that is trying to be more active on the list and
> in
> > the code. If I can help in this type of area by trying patches and voting
> > for
> > ones that work, that would be great.
> >
> >
> >
> >
> > rom: Taylor, Jason <[EMAIL PROTECTED]>
> > Subject: Applying patches
> > Date: Fri, 4 Oct 2002 10:43:48 -0700
> > Content-Type: multipart/alternative;
> > boundary="----_=_NextPart_001_01C26BCD.98088C80"
> >
> >
> > Maybe we can come up with some process of reviewing patches so that
> > struts-dev subscribers can take care of some of the quality control tasks
> > and committers can review the reviews, if that makes sense. Struts is so
> > good at divvying up work between people and creating specialized tasks
> that
> > somehow make up a development process, it seems appropriate that the
> process
> > of managing the framework itself should benefit from similar
> specialization.
> >
> >
> > Is there anything we can do to help committers review patches? Maybe
> people
> > could post their own digests of the bug list that prioritize bugs, scope
> the
> > issues and give their opinions on the possible solutions or the posted
> > patches that are available. We could also find bugs that we recommend be
> > dismissed to get them off the list. Maybe morale would improve if there
> was
> > a sense that the effort required was actually *not* infinite.
> >
> > __________________________________________________
> > Do you Yahoo!?
> > New DSL Internet Access from SBC & Yahoo!
> > http://sbc.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
