<div class="gmail_quote">On Tue, May 5, 2009 at 1:09 PM, Alexandr Smirnov <span dir="ltr"><<a href="mailto:asmirnov@exadel.com">asmirnov@exadel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The RichFaces test project has little bit more then simple mock objects;<br>
it simulates a real web server which works with any JSF implementation,<br>
and has integration with HtmlUnit as well, so it can be used for<br>
functional and compatibility tests. I've been created that project<br>
especially for JSF 2.0 tests ( because there are no mock projects for<br>
JSF 2.0 api yet, and API was changing too often ). But that project<br>
really has no JSF or RichFaces dependencies, therefore it could be used<br>
to test any web framework, including Seam as well.<br>
<br>
But using real implementation for simple test seems overloaded,<br>
therefore it makes sense to combine 'staging' server with mock objects<br>
too. Because that test environment has no direct references to<br>
particular framework, we can make an independent test project,<br>
applicable for both RichFaces and Seam.<br>
Because we already have at least two candidates for common libraries (<br>
that are tests and bean validators, the CDK seems as third ), I think we<br>
should create 'common' module that will holds all shared libraries for<br>
Jboss Seam and RichFaces projects.</blockquote><div><br>Frankly, to me, that's what Seam is...our common module. I don't want to introduce some new, generic name. Seam is the JBoss middleware module set. It's no longer a container of any sort. Web Beans is now the core programming model and RichFaces is the UI component set and programming model. So by depending on Seam, you are doing nothing more than depending on a common module in JBoss. Hence the reason I want seam-mock.<br>
<br>There are many needs for testing. I want to focus specifically in this module on completely standalone beans. No server logic. No real web calls or anything of the sort (*maybe* XML parsing in specialized subclasses). It is for unit testing, or as close to unit testing as you can get, with servlets and JSF APIs. We can of course have other modules. But this is the super lean one.<br>
<br>...and yes, let's be sure to leverage all prior work...and work together ;)<br><br>Cheers,<br><br>-Dan<br></div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>
basis, personal or other work matters can sometimes keep me away<br>from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>
caught in the spam filters. Please don't hesitate to resend a message if<br>you feel that it did not reach my attention.<br>