Servlet - org.jboss.seam.mock.servlet

On Thu, Apr 30, 2009 at 5:14 AM, Christian Bauer < christian.bauer(a)gmail.com&gt; wrote: > > On Apr 29, 2009, at 17:10 , Dan Allen wrote: > > Servlet - org.jboss.seam.mock.servlet >> > > There is a set of extended mock classes for various Servlet APIs in > /examples/restbay, which we use for REST testing. These should be merged > with the (pretty anemic and useless) core mocks in Seam3. Excellent. Just the pointer I was looking for.

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

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

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

The RichFaces test project has little bit more then simple mock objects; it simulates a real web server which works with any JSF implementation, and has integration with HtmlUnit as well, so it can be used for functional and compatibility tests. I've been created that project especially for JSF 2.0 tests ( because there are no mock projects for JSF 2.0 api yet, and API was changing too often ). But that project really has no JSF or RichFaces dependencies, therefore it could be used to test any web framework, including Seam as well. But using real implementation for simple test seems overloaded, therefore it makes sense to combine 'staging' server with mock objects too. Because that test environment has no direct references to particular framework, we can make an independent test project, applicable for both RichFaces and Seam. Because we already have at least two candidates for common libraries ( that are tests and bean validators, the CDK seems as third ), I think we should create 'common' module that will holds all shared libraries for Jboss Seam and RichFaces projects.

Ok, do you start that project ? RichFaces uses Shale mocks now, but I wish to replace that with something more convenient. I can help with development and contribute existing test classes from richfaces to the new mocks project.

I have an idea for the mock testing project. While Shale and all other projects use one base class where all mock objects are initialized, the new one can utilize Seam/WebBeans 'inverse of control' pattern, where necessary mock object should be injected in the same way as components use: public class FooTest extends .... { @in private FacesContext context; public void testBar() { ............... context.get...... ............... } Therefore all mock initialization code can be moved into separate class, that may be used with any test framework ( jUnit 3/4, testng.... ). Dan Allen wrote: > > > On Tue, May 5, 2009 at 7:22 PM, Alexandr Smirnov <asmirnov(a)exadel.com > <mailto:asmirnov@exadel.com>> wrote: > >    Ok, do you start that project ? RichFaces uses Shale mocks now, but I >    wish to replace that with something more convenient. I can help with >    development and contribute existing test classes from richfaces to the >    new mocks project. > > > Yes, it is here:  http://anonsvn.jboss.org/repos/seam/modules/trunk/mock/ > > However, give me a day or two while I import what we have from Seam (I > need to bring in the mocks from seambay and a couple other places). > > Exactly, we want to get away from Shale. > > -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

Speaking of Shale, I really dislike the idea of one huge factory. I much prefer builders if you need to assemble an aggregate object....for instance, if you need FacesContext with ExternalContext mocked out. And you don't often need everything setup anyway. It depends on the test. As for the injection, we can think about tying that into the @Artifact framework from the JBoss test harness (created for Web Beans Pete and co)