myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [GSoC] Automated webapp tests API draft
Date Fri, 18 Jun 2010 10:14:50 GMT
Hi

I think in my personal opinion the target of myfaces-test and what is
proposed in this project are two different things.

- myfaces-test aims to provide a jsf test environment for artifacts like
components, attached objects(converters, validators ....) or things related
to myfaces core itself (test state saving stuff, if some algorithm is
working or not,....). The usual test case is for example the user wants to
know if the component do something, or if the renderer output some expected
output.

- The proposal for GSOC aims to provide a jsf test environment that will use
different containers and the objective is make test that could be run
against different server configurations (for example, run some tests against
different web.xml configurations).

Really what I like about use myfaces-test is the ability to run the tests
using junit in eclipse and set breakpoints. It is very, very simple, so if
it is necessary to make tests about some component or some feature in
myfaces core, in my opinion the preferred option will be use myfaces-test.
Sometimes it is not required to test in different containers or server
configuration to know if the code works or not, so the important thing to
keep in mind is use the right tool for the job.

I would like to have the ability to set breakpoints with eclipse or other
IDE, at least on a single container with this tool, but I think as long as
it can do what is expected it is ok.

Let's see what happen with this project.

regards,

Leonardo

2010/6/18 Gerhard Petracek <gerhard.petracek@gmail.com>

> hi,
>
> imo the mentioned gsoc project should provide an easy to use api which
> reduces the amount of test-code to a minimum.
> the tests should run in the embedded versions of the available containers.
> therefore it's possible to test jsf applications, component libs,
> extensions,... with real jsf implementations and without using mocks for jsf
> artifacts. furthermore, it should be possible to run the same tests with
> different servers as well as server configurations.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
> 2010/6/18 Leonardo Uribe <lu4242@gmail.com>
>
> Hi
>>
>> I have checked the status of myfaces testing stuff and I did a list of the
>> "oportunities" to make myfaces even better.
>>
>> - Enhance myfaces-test project: In that project we have just moved
>> shale-test stuff and did some updates/fixes to make it work in jsf 2.0. But
>> it is becoming more critical to really update/enhance the code, because it
>> is becoming very common to add custom stuff on myfaces-impl to make some
>> tests work.
>>
>> - Myfaces-test specific code: Since now we have facelets inside myfaces,
>> one possibility is create a jar file that works with myfaces core code and
>> make complex tests that requires run facelets VDL code. Now in myfaces core
>> we have a test suite for composite components that uses that kind of stuff,
>> but we can't do that type of tests outside myfaces (for example a component
>> library). I would like to run a full request lifecycle using mock objects
>> without deal with a servlet container, just write my JUnit test and that's
>> it.
>>
>> - Test app for myfaces core stuff that we can't test using junit: There
>> are some new stuff added to myfaces core 2.0 that we just can't test it with
>> junit + myfaces test. Some examples are flash scope, ajax, combinations of
>> post-redirect-get pattern. It is necessary to create some tests for this
>> stuff to enhance stability of these features.
>>
>> In my understanding, the direction that took this GSOC project is
>> different. The objective is create a new API more focused in test web
>> applications deployed on a container, and use myfaces specific code to
>> "bridge" between the test and myfaces implementation running in the
>> container (at this point it is not very clear the steps to make a test run).
>> It looks good, so I'll keep an eye on it. I suppose that the resulting code
>> could be a new module of myfaces-test. I hope as the name of this project
>> suggest, one contribution will be a automated webapp for test myfaces core
>> 2.0, but it seems more important in the future have a new api for testing.
>>
>> Right now, almost all code is in place for tomahawk core20 project, but it
>> is necessary to test it before make any release. So I'll start to work in
>> the first two ideas, aiming to do an official release of myfaces-test
>> project, and I'll keep an eye on the results of the GSOC project. It could
>> be good to know if some svn repo is used to publish the advance of this
>> project (for example http://code.google.com).
>>
>> regards,
>>
>> Leonardo Uribe
>>
>
>

Mime
View raw message