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]
