Re: [seam-dev] the parody of mocks in JSF

agreed - as long as RF can grab the individual module from seam ( and not pull in others ) it should be fine. The concern would be too many cross project dependencies making working with just one of the projects tricky ( and harder to productize ). On Tue, May 5, 2009 at 8:33 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Can we share these mocks like we discussed for graph validation - RF > imports the module from the "Seam" space - but the Seam module doesn't > depend on other Seam code? > > > On 30 Apr 2009, at 15:13, Jay Balunas wrote: > > You may also want to check out >> http://www.jboss.org/community/wiki/TestDrivenJSFDevelopment >> >> Alex Smirnov has been working on this to help with RF 4.0 development. >> Perhaps we can collaborate. >> >> On Wed, Apr 29, 2009 at 11:10 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; >> wrote: >> It's hard to believe that for as long as JSF has been around, the only >> decent repository of mocks for the JSF API comes not from the >> implementation, but rather from all but dead and irrelevant project at >> Apache (Shale). Of course, Seam 2 forged it's own path and has a healthy set >> of mocks, although still somewhat incomplete and vagrant. In the Seam 3 >> spirit of modularity, I would like to migrate the Seam 2 mocks into a mock >> module in Seam 3 that provides mock/stub object for various Java EE APIs. I >> plan to categorize them by spec under the org.jboss.seam.mock folder >> >> JSF - org.jboss.seam.mock.faces >> Servlet - org.jboss.seam.mock.servlet >> etc >> >> This module should not depend on any other module so that it is easy to >> reuse, perhaps even outside of the Seam framework. Perhaps seam-mock can end >> up replacing Shale test. Who knows. We'll just let it play out. Please >> contribute your ideas/use cases! >> >> http://anonsvn.jboss.org/repos/seam/modules/trunk/mock/ >> >> As for the functionality, my feeling is that the mocks should be >> functional as long as each class behaves like a bean. That means it >> shouldn't parse XML documents or make similar assumptions. But they should >> be easy enough to extend that perhaps you can add that functionality in your >> test case or we can think about providing an additional subclass or helper >> if the need is common (perhaps parsing an web.xml document). >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://in.relation.to/Bloggers/Dan >> >> NOTE: While I make a strong effort to keep up with my email on a daily >> basis, personal or other work matters can sometimes keep me away >> from my email. If you contact me, but don't hear back for more than a >> week, >> it is very likely that I am excessively backlogged or the message was >> caught in the spam filters. Please don't hesitate to resend a message if >> you feel that it did not reach my attention. >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> >> >> -- >> blog: http://in.relation.to/Bloggers/Jay >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete > > -- blog: http://in.relation.to/Bloggers/Jay