It sounds like StrutsTestCase could really take advantage of AOP. The whole notion of injecting a custom request processor to intercept the returned forward could be handled by an aspect.

-Bill Siggelkow

Ted Husted wrote:
On Mon, 22 Nov 2004 18:55:36 -0600, Joe Germuska wrote:

From
http://sourceforge.net/projects/strutstestcase/ I see that there
are four developers (including Ted) but I don't see a way to gauge
the involvement of them.


I was the first developer that Deryl added, which was a little over a year ago, 
I think. Soon after that, I became distracted with other matters. But when I 
was using Struts TestCase, I found it very helpful. Using JUnit against the 
business layer and WebTest against the view layer also works, but TestCase 
actually probes the Struts Configuration, which is not something you will get 
from any other tool.

The CVS is online at SourceForge, so you can poke around and see who's been 
authoring recently. You could also run the Maven changelog against the CVS to 
generate statistics. [Or just ask Deryl :)]

Likewise, the Issue Trackers and User Forums, are all online where they can be reviewed.

On the tracker, I see that nearly all the tickets have been resolved. Some are 
rather old, but that usually means no one has found a resolution yet. (Much 
like ours.)

In the forums, I note that there is a lot of user-to-user communication, which is the best telltale of all.

Here's a post Deryl made to the dev list in June.

--- Original Message ---
From: "Deryl Seale" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Fri, 11 Jun 2004 10:25:58 -0700
Subject: Integrating StrutsTestCase into Struts codeline



Hello, all.   My name is Deryl Seale, and I am the maintainer of
the StrutsTestCase library.  Some time ago, Ted Husted contacted me
about integrating StrutsTestCase into the Struts codeline,
effectively making it a part of the Struts offering.  I've seen
this idea crop up a bit more on this list, and as well, I think it
would benefit StrutsTestCase by opening it up to a larger body of
developers.  To that end, I thought I would broach the topic, and
get your collective thoughts on how best to pull in the
StrutsTestCase code.

I've spent a good amount of time during the past year keeping apace
with Struts development, since StrutsTestCase needs to know about
the Struts internals to do its job.  The major part of STC is
verifying that an Action returns an expected forward, which right
now comes down to comparing an expected to the actual forward path,
*not* the forward name.  A bulk of the STC code contains
contrivances to get this information, and it works well.. to a
point.  Extensions such as Tiles pose a problem, however, since the
path that is forwarded can be the same for many tiles, and so path
comparison breaks down.

What I really need is some way to get the forward just as it's
returned from the Action, and the RequestProcessor seems to be the
answer.  In fact, I've built a prototype where I "inject" my own
RequestProcessor into Struts, and in doing so, I can grab the
forward and use it for validation, which is much more robust than
path comparison; as well, it cuts out about half of the STC code
base, which is swell. Unfortunately, that approach only works if no
other RequestProcessor is used, since chaining of RequestProcessor
objects is not currently supported (which I know is a hot topic
right now) -- and that is not feasible for most Struts projects.

So, anyway, that's where StrutsTestCase is right now, and I'd like
to get to the point where I can more reliably get inside Struts to
get the validation information I need.   I like the idea of using
RequestProcessor, but there are obviously large architectural
changes required for that be a real solution.  If there are other
ways to attack this problem, then I'd like to hear about them.  And
finally, I'd like to hear your thoughts and suggestions for getting
StrutsTestCase to be a part of Struts.

thanks.
--Deryl

--------------------------------------------------------------------
- To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to