[seam-dev] the parody of mocks in JSF

[Jay Balunas]

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 at redhat.com> 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 at gmail.com>
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>>
>> --
>> blog: http://in.relation.to/Bloggers/Jay
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090505/83bb2983/attachment.html