Hi Cosmin,

Thanks a lot for your great work! I already tried it out a couple of times
and it works really great.

I will integrate the code into the MyFaces codebase after GSoC ends so that
we all can start working on this framework. Later, when we have the first
releaseable version in place, we can begin to write MyFaces core (and
tomahawk, codi, ext-val, trinidad, tobago,....) tests with it, and this will
be kick-ass!

Regards,
Jakob

2010/8/10 Martinconi Cosmin <cosmin.martinc...@codebeat.ro>

> Hi,
>
> The GSoC program for this year is almost finished and I wanted to let you
> know about the progress and the current state of the "Automated webapp tests
> for MyFacescore and extensions", my project for this GSoC.
>
> You can follow the API and the implementation(SVN google code) on:
>
>    - http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
>    - https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
>
> The API that I have followed is the one from the wiki, including small
> changes like introducing "@Tester" and "@Assertable" instead of "@Inject"
> for the resource injection configuration. The "@Tester" will inject an
> WebappTester instance that will provide all required functionality, and
> "@Assertable" to inject proxy instances for assertions.
>
> Also an "@ConfigurationTestSuite" configuration was provided, where the
> user of the API can specify a list of configurations and the API will run
> the test case with all the configs, meaning an "n" configured test case will
> generate "n" tests for the same test instance but with each of the specified
> configs.
>
> The API provides the following actions: click(buttonId),
> input(string).into(fieldId); and the assertions:
> assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId) and
> expectCall(methodCall/ELexpression).in(PhaseId)
>
> I am currently working on some issues regarding expectCall() that I
> overlooked, but this should be functional by the end of this week. Other
> drawbacks of the project are that I couldn't get rid of the method:
>
>     @Deployment
>     public static Archive<?> createDeployment() {
>         return webappTestCase.createArchive(null);
>     }
>
> Arquillian is looking for a method annotated with @Deployment and if such a
> method is not provided it fails the test run. Another inconvenience is that,
> for the embaded Tomcat container, Arquillian requires, for now, a servlet
> mapping in the web.xml of the testing webapp, like:
>
>     <servlet>
>        <servlet-name>ServletTestRunner</servlet-name>
>
> <servlet-class>org.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner</servlet-class>
>     </servlet>
>     <servlet-mapping>
>        <servlet-name>ServletTestRunner</servlet-name>
>        <url-pattern>/ArquillianServletRunner</url-pattern>
>     </servlet-mapping>
>
> I would highly appreciate any feedback, comments or suggestions on the
> project and the implementation.
>
> Regards,
> Cosmin
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Reply via email to